IIS缓存“布局页面”在以下路径上找不到。错误
问题
我有一个网站在IIS运行的 。如果我重命名或删除一个布局页面之一.cshtml /views/views/立即开始在“ Yellow屏幕错误”之后开始抛出
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
令我惊讶的是，如果我重新创建或重命名文件，黄色屏幕持续存在。为什么这个特定的500错误粘性？
我目前认为这与IIS有关，并且与错误处理特别相关。该站点立即检测到布局页面文件是否丢失。它没有立即意识到文件何时恢复原状。
谢谢！
一些有趣的线索
- 到目前为止，我在我尝试过的所有网站上都发生了 。它与特定网站无关，
- 我同时在两个网站上尝试了此网站。在一个网站上，我反复并始终如一地刷新页面，希望取得成功。另一方面，我独自留了几分钟，然后再次检查。我独自留下的网站将解决其问题，并在磁盘上再次找到布局页面。我不断提出请求的网站似乎无限期地显示错误。
我尝试的是，
- 我使用Umbraco的默认路由以及使用自定义路由的常规MVC页面复制了Umbraco网站上的问题。两者的问题都是相同的。
- 当我重现黄色屏幕错误时，我没有在IIS中配置的输出缓存
- ，我能够在多个浏览器中重现错误，因此我不相信它与浏览器缓存
- 有关在root web.config和
fcnmode设置为fcnmode =“ single” - 我已经摆弄了web.config
customErrors和httperrors。我在这里没有做任何事情都影响了这个问题。 - 我能够在没有自定义代码的网站上重现问题。没有CDN。没有负载平衡器。
版本
- IIS：我已经在运行IIS 8的Windows Server2R2和Windows 11运行IIS 10
- cms的Windows Server2上复制了该问题：到目前为止，我已经测试过的所有网站都是Umbraco 7网站。但是，我已经在使用Umbraco Out Box路由以及刚刚使用MVC设置并且不利用Umbraco设置的页面上复制了该问题的问题。
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
httpRuntimein the root web.config and thefcnModeis set tofcnMode="Single" - I've fiddled around with the web.config
customErrorsandhttpErrors. 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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它似乎是
fcnmode =“ Single”的行为的一部分。参见 https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-wormework-framework-4.8 。这不是缓存的问题。该网站的文件更改通知（FCN）的配置方式是一个问题。当我使用
fcnmode =“ single”时，会在重命名文件上的粘性500行为发生，但是当我使用fcnmode =“ default”时，就会发生。fcnmode =“单个”将仅导致一个对象监视文件更改。该单个对象负责监视主目录和子目录中文件的更改。fcnmode =“ default”将产生一个单独的对象，以监视每个目录的文件更改。Umbraco站点，默认情况下，使用
fcnmode =“ Single”。这是有道理的，因为Umbraco站点在/app_data/的非常深度嵌套的目录下缓存。这可能会导致许多这样的监视器，因此它会影响站点的性能。有一个很好的解释FCNMode以及为什么在这里对Umbraco很重要： https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/不幸的是，在某些情况下，单个文件监视器似乎会错过文件的重命名。
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 useFcnMode="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.