When my MVC app is first deployed it works fine, up until the point when the application pool is recycled. After that, none of the routes work and I receive 404s for everything. Forcing a rebuild by editing the web.config or redeploying will bring the site back online, until the next recycle.
My MVC setup is a bit atypical. I'm doing quite a lot on startup, such as scanning assemblies for routes that need to be loaded. I feel like there must be some Global.asax event that only fires on the initial build but is not run on a recycle.
What are the differences between the recycle and the rebuild in terms of startup events?
Thanks,
Brian
The answer is apparently nothing. My problems stemmed from a garbage collection issue where resources weren't being cleaned up.
Related
The Problem
I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?
I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.
Thanks!
Some interesting clues
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.
What I've tried
I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
I don't have output caching configured in IIS
When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.
Versions
IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.
It appears to be part of the behavior of FcnMode="Single". See https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.
The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".
FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.
FcnMode="Default" will result in a separate object to monitor file changes for each directory.
Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/
Unfortunately, it appears that the single file monitor can miss renames of files in some cases.
I've got an ASP.NET MVC app where the Application_Start event appears to not be firing. The symptoms are that an NLog log statement in that handler does not generate a log entry, and none of my routes get populated (so all my requests for controller actions return a 404).
Static files on the server (eg, favicon.ico) are served correctly.
I have log statements in Application_BeginRequest and Application_EndRequest. Those do generate log entries, both for the controller methods and the static files, so I feel pretty confident the app pool is configured correctly.
The problem shows up on our staging server, but not my local machine or our dev server.
Any idea what would cause this?
It ended up being a combination of things. The root cause was inconsistent versions of DLL's, and I solved that by configuring the project to copy the problem assemblies to my bin folder. On top of that, there was some code in Application_Error that was preventing the actual exception from being shown.
I have an MVC 5.x app which has had its views precompiled and merged into a single assembly. Even after all this the first request to a view after AppDomain startup is slow, it does not matter which view is requested as they are all slow the first time the view is requested. Digging in with MiniProfiler I can see it is the "Render" time on the view which takes the majority of the time and upon additional requests to the view the Render time is reduced by about 90%. So to be clear it is this first-time Render that is taking allot of the time. I was not expecting to see this bit of slowness due to the fact all of views have been precompiled and I do not believe it is the JIT that is causing this massive slow down...anyone have any guesses or insights?
Please note, this is not the very first request of a web application, this is the first request of a particular view/page. For example, for the test below the app had been running for hours and was taking requests constantly but the test captured the first request for this view.
First Request
Second Request
Strange! In order to be 100% sure what exactly happens, however, I'd do the following:
I'll redirect the run-time compilation (yes, there'll be one since at
least Global.asax needs to be compiled) like this:
<system.web>
<compilation debug="true" targetFramework="4.5" tempDirectory="c:\temp\asp.net" />
...
</system.web>
I'll investigate the contents of the folder before and after the
first run. Maybe it'd be even better to have a copy of the original.
From your description of the problem it seems like everything should be just fine and there would be no differences between the runs. Still comparing contents of the folder before and after may reveal some difference.
Another cause might be some caching but I can guess you have already sorted this up.
I struggled with the exact same issue for months: It happened to me in some views only.
Apparently, the rendering of the views is not that straightforward as I thought, since MVC needs to run a couple of operations to determine the exact .cshtml to use for an action, its partial views if you have any, etc etc.
What did the job for me is to use Razor Generator which processes Razor files at design time instead of runtime. (if you wanna give it a shot, I suggest first trying it with a view you know takes time to load at first attempt).
From the website:
One reason to do this is to avoid any runtime hit when your site
starts, since there is nothing left to compile at runtime. This can be
significant in sites with many views.
The downside of implementing the Razor Generator is that you no longer need the .cshtml files: so if you want to change a view, you have to recompile the project. But that's not an issue necessarily, at least not for me.
Install the Razor Generator from the VS extension gallery first (like it's explained on the website) and then the nuget package.
Trust me: you are gonna be so relieved you're gonna cry ☺
I have a couple of MVC3 web applications in my project. I have added entries to my hosts file as follows:
127.0.0.1 local.mysite.com
127.0.0.1 admin.local.mysite.com
Both application's properties are set to use Local IIS Web server with the project URLs as follows:
http://localhost/mysite.web
http://localhost/mysite.web.admin
When I try to debug from Visual Studio, I can debug the "mysite.web" project from both http://localhost/mysite.web and http://local.mysite.com
For some reason, the "mysite.web.admin" project will only debug from http://localhost/mysite.web.admin
Any breakpoints I set will not be hit when I browse to http://admin.local.mysite.com
I dont recall doing anything different\special to allow "mysite.web" to be debuggable from other domains.
Any ideas?
Put a Debug.Break(); in you code and see what happens. You might have to create an app pool that runs as Bryan to use this approach.
Why do you need to use http://admin.local.mysite.com ?
This is not a MVC question, there is probably lots of info if you look/ask in Web Forms.
Can you debug from http:///mysite.web.admin ?
I wish I had a more detailed answer but all I can say is that after trying dozens of things found across the web, everything began working after a simple reboot.
My best guess is that the DNS resolution was cached somewhere. I flushed my DNS, restarted IIS, restarted VS2010, etc but none of them seemed to be the issue.
I dont know where it was cached but the reboot solved it.
I'm getting a View not found exception when my ASP.NET MVC site is configured with is home directory pointing to a network share in IIS.
The weird thing is that this error appears intermittently, sometimes the view loads fine and others the same view fails.
I've tested this in IIS 6 and 7, both have the same problem.
I also have other ASP.NET WebForms sites on the same web server configured in the same fashion (files from a network share) and they have no problems, which makes me I think this is a bug in the MVC framework, specifically in the view look up process.
Have anyone else experienced something similar and/or know a solution?
Thanks,
Rafael.
The connection to shared drives is not persistent, meaning that the connections are "refreshed" in a sense when accessed. Since web forms compiles the entire site at run time the pages are accessed once during the compilation process (in a pre-compiled app you down even actually need the aspx pages).
However in MVC only the code in the controllers is compiled, leaving the views to be accessed by request at run time. If the view is not immediately available the MVC engine will throw an exception.
So if you hit MVC app the first time it will throw an error saying it can't find the view, but on subsequent requests immediately after it should find the view without issue. Until the connection state to the shared folder is closed, when you will get the error again.