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.
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 have a precompiled MVC site which runs successfully on multiple servers, and on multiple sites within each server.
One particular site a few days ago suddenly stopped working, returning
HTTP Error 403.14 - Forbidden
I couldn't find anything that would cause it, and rebuilt the site using the same source code as other sites on the same server, in a different folder, and the site ran fine for about 24 hours before once again suddenly experiencing the same error.
There is nothing in the Windows logs (Win 2K12 Server) or in the IIS (6.2) logs (other than confirming the 403). This particular site is running on a Virtual Server in Azure, but plenty of other sites are too, including on the same virtual server using the same source code and settings (other than domain name bindings).
I've currently moved the binding to a different process which is working fine, but I really need to get to the bottom of this in case it suddenly happens again.
I've googled this for days without success. Turning on directory browsing works, but of course not something I can or want to permanently do with MVC. Both home and MVC route requests return the same result, but calls for specific files (eg, a text file in a sub-folder) are successful. That certainly suggests a MVC-specific issue. But I can't work out how to specifically isolate the issue.
Obviously I've reset the application pool, the site itself, and indeed set up a new site using the same application pool (which is working currently, but I'm worried it too will suddenly break at the worst time).
Does anyone have any pointers for working out the main cause, please?
We have hit a strange issue which I cannot find any reference to while searching the web.
We have a small number of ASP.Net MVC based apps on a web server which fail after their app pools have recycled.
The default/home returns a blank page, and if you try to go to other pages you get a 404. IIS still serves static content such as css or js if you specifically go to them.
Nothing is recorded in the Win or IIS logs as errors or warnings, nothing stands out.
We can resolve the issue by either redeploying the app or deleting the sites compiled files in the Temp ASP.Net folder, forcing a recompile. But obviously once app pool recycles again it breaks.
The only thing that's changed on the box is a installing .Net Framework 4.7.2 along with a few Win Updates.
However dev versions of the same app or on another box which work fine and that's also been updated to 4.7.2 etc.
How can I solve this?
I have a strange issue with an Asp.NET MVC application.
Using Asp.NET MVC 3 Preview 1 on IIS 7.5 - Integrated
After building the application everything runs fine. Then after some random amount of time (or sometimes after updating a view or js file) the application dies.
Meaning, requesting the root page, I get the 403 error and requesting any other page I get a 404 error.
After a rebuild everything works fine again for a little while until it dies again.
I am seeing this on two different development machines. Also, I have another application which is very similar (MVC 3, IIS etc) on both dev machines and this one runs without problem. I have inspected the config files in detail and cannot see anything of notable difference.
Does anyone know what could cause an application to die or where to look for further information? (I can still access elmah.axd though no information is there).
There's not much to go on here, but the 403 and 404 are clues that at least ASP.NET routing is not working; 403 is coming back because the web server thinks you want to do a directory browse, 404 because your request doesn't have a valid corresponding resource.
Since you are using the new version of MVC, I would suspect the issue may lye there. When you get the error condition, can you browse to a regular .aspx page? Does it execute server side code correctly?
You have the site hosted in IIS 7.5, not just the built in Visual Studio web server, right? Is it possible to turn on monitoring/event logging to see if IIS is taking a hit?
I apologize for not having any actual answer, sounds like you have a tough issue to debug.
Good Luck!
I am seeing a weird behavior on IIS7 on Windows 2008. I have an ASP MVC application installed and fully functioning. Every time i reset its application pool, the website stops working and displays a 404 error.
The only workaround I found for this is:
1. Rename default.aspx, global.aspx, and web.config to something else
2. Create a simple index.htm file and place it in the root
3. Browse to the site (which correctly displays index.htm)
4. Rename the three files back
At that point the site will load properly and work as expected. Anyone has any idea why that would happen?
Thanks!
Check out the Windows Event Viewer, under Application. The website might be throwing an exception each time it attempts to restart.