-1

We are deploying an ASP.NET Framework MVC web application to an on-premises Windows server 2019 data center running IIS 10.0. We’ve previously deployed this same application to an on-premises Windows 2012 server running IIS 7.5 without any issues. However, since migrating to the new server, changes to a specific CSHTML file are not reflected in the running website.

Details

  • The web application is running on the same IIS server as other ASP.NET applications, not of which are experiencing this issue.
  • This web application is the only MVC application on the server, so the issue might only affect MVC applications.
  • The only change to the CSHTML file is the href attribute of an anchor tag. When examining the file in the browser, it does not use the updated href.
  • The failing file is named /views/cms/about.cshtml
  • There is another file named /views/home/about.cshtml
  • After modifying several CmsController actions (About, Foo, and Bar), we've successfully changed the deployed behavior for /cms/foo and /csm/bar, but not /cms/about, so the About action isn't being invoked; thus, IIS appears to be caching the result of the /cms/about route, not the /Views/Cms/About.cshtml file

We are currently corresponding with a Microsoft consultant, but even they are stumped thus far. Any ideas are appreciated.

What we’ve tried thus far

  • The cshtml files on the server are correct; thus, it is not a deployment issue
  • The “last modified” date of all files in the site folder – including binaries – are correct
  • Neither clearing the browser cache nor accessing the site from a private browsing context fixes the issue; thus, it is not a client-side issue
  • The server’s localhost serves the old page; thus, it is not a network issue
  • Changes to static resources are reflected in the browser; thus, the issue only affects CSHTML files
  • The old version of the file is served even after deleting or renaming the file; thus, a cache is most likely involved somewhere
  • Deleting the Temporary ASP.NET Files folder does not resolve the issue.
  • Recycling the app pool in IIS does not fix the issue.
  • Restarting the application in IIS does not fix the issue.
  • Restarting the IIS server does not fix the issue.
  • Disabling output caching does not fix the issue.
  • Though this problem is like this other problem, the solutions listed did not work.
  • This sounds similar but is not a long-term solution.
  • added 6/22/2023: re-deploying the application does not fix the issue

After each of these attempts, the server continued to serve the old CSHTML file.

Matt Crow
  • 1
  • 2
  • Does the same happen when you use private browsing/incognito mode on your browser? Have you tried redeploying the project? – samwu Jun 22 '23 at 05:29
  • @samwu I've updated my initial post to clarify. We've already tried those solutions, and have ruled out the possibility of a client side problem. Redeploying doesn't work, but I'll be checking today if something is going wrong with the deployed artifacts. Good ideas though – Matt Crow Jun 22 '23 at 15:38

1 Answers1

0

Solution

As it turns out, the admins can override the content of webpages so they don't have to open tickets when they need grammar- or other small changes. Whenever requests were made to the /cms/about route, the app saw the content override, then rendered that instead of /cms/about.aspx. We resolved the issue by modifying the overriding content.

Matt Crow
  • 1
  • 2