I have an ASP.NET WebForms website which has a few Web.Config files for dev/UAT/production (the appropriate web.config is deployed to the relevant environment) - all of which reference a shared rewrite rule file - so that the rewrite rules themselves don't have to get duplicated into each web.config. This works great
<rewrite>
<rules configSource="WebConfigRewrites.Config" />
</rewrite>
However, if I add a new rewrite rule to this file, then the rule doesn't take effect until I restart IIS. If I recycle the application pool, or restart the website in IIS the new rule doesn't work (e.g. a rewrite URL will throw a 404 until I restart IIS)
Is there any way around this? If I bring in the rules into the web.config then recycling the apppool, or even updating the web.config will cause these new rules to work - but at the cost of having to duplicate all the rules across several files.
Having to restart IIS itself is really rubbish, as it causes the site to instantly respond with a "service unavailable" 503 error.
Is there any other way around this?
Server is Windows Server 2016, IIS 10.0.14393
As the discussion under comments is lengthy, post a summary here to avoid confusion.
Usually your edits in URL rewrite rule section in web.config takes effect immediately, as IIS monitors <system.webServer> actively in web.config files.
But, when you moved the rules to an external file via configSource, you observed that changes to those rules are no longer picked up by IIS immediately. That seems to indicate IIS does not monitor such external files actively. If you want to confirm that's by design or not, the only way is to contact Microsoft support via https://support.microsoft.com.
The workaround is also easy that you "touch" the monitored files like web.config, so that manually trigger configuration refresh.
Normally we do not need to restart IIS after changing web.config.
Changes web.config will trigger the app to be reloaded by IIS as soon as there are 0 connections left to the app. You can stop and restart the app pool. Recycling app pool is not recommended and you should stop/start the respective app pool where you update.
Have you tried stopping the site first and then restarting it? 404 error means that IIS has detected that web.config has been updated. You can also generate logs to view details.
Related
Using IIS 7 with a deployed dotnetcore 2.1 or 3.1 web API alone in an application pool, we discovered while looking at Process Monitor on the server, the w3wp.exe workers were logging many errors where they were apparently looking for a web.config. They checked every route in the api's route. The expected behavior was that the w3wp.exe (an IIS worker) would "hand off" the request to the dotnetcore application's routing, which would find the endpoint, but instead, it appeared to be also checking for a web.config. The process monitor revealed w3wp.exe QueryOpen NAME NOT FOUND and PATH NOT FOUND errors.
I looked at a few articles and concluded it was a problem with web.config inheritance, and there must be some setting in IIS or a dotnetcore configuration that was dictating the behavior of checking each API route path as if it were a virtual directory folder system that might contain a new web.config. The benefit would be that you could have a different web.config in a sub-application, but we didn't want that benefit and we didn't want these IIS workers blowing up the logs with thousands of these errors throughout the day. We found an insanely simple solution that an IIS admin might say "duh" but will hopefully save someone out there some time.
We found the answer on an old blog.iis.net post about web.config inheritance (https://blogs.iis.net/steveschofield/control-web-config-inheritance-with-iis-7-asp-net-options). There is a configuration called allowsubdirconfig that directs the w3wp.exe worker to check subdirectories for a web.config file. Here's how you change it in IIS applicationhost.config that can be found through IIS Manager:
Go to configuration editor
Go to system.applicationHost => sites => virtual directory defaults
Set allowSubDirConfig to False
We also discovered that Microsoft recommends you use this setting for hosting dotnetcore applications on IIS
Skipping the additional file operations can significantly improve
performance of websites that have a very large set of randomly
accessed static content.
https://learn.microsoft.com/en-us/previous-versions//dn529134(v=vs.85)?redirectedfrom=MSDN
Keep in mind, if you use this setting, you'll need to come up with a solution to separate applications that use or don't use the setting.
Related issue with MVC:
ASP.NET MVC security and IIS allowSubDirConfig configuration
My asp net core project does not have a web.config file, so what I do after publishing is to go into 'Server Explorer' toolbar and manually open & edit the remote web.config to re-add the redirect rules. All works great until I publish again to update the app. Then I have to go through the manual steps again to paste my redirect rules back in. So in short, every publish seems to transform the remote web.config back to bare bones.
Is there a better way around this? I've already tried making a local version of web.config with all the redirects inside, but it seems that publishing completely ignores it.
Thanks!
You can use redirect middleware to perform redirections. Check
here.
I have an MVC app hosted on an Azure Website.
I have custom errors enabled and working (when not publishing):
<customErrors mode="On" defaultRedirect="~/Error/NotFound" xdt:Transform="Replace">
<error redirect="~/Error/NotFound" statusCode="404" />
<error redirect="~/Error/NotFound" statusCode="403" />
</customErrors>
When I publish the website from Visual Studio, if I try to visit the site while the dlls are being updated, I get a nasty IIS error.
I'm surprised that Azure doesn't wait to "tie down" the new version until the publication is complete, to avoid this scenario. Is there a way to achieve this "instantaneous switch" behavior?
And/Or - How can I prevent this error from being displayed?
I can't say this would be unusual. Depending on size of the deployment it may take a while for IIS to restart and reload leading to 503 Service Unavailable or similar errors in the meantime. CustomErrors won't help you here as the ASP.Net pipeline isn't even being reached at this point. What Azure Website level are you running on (Free, Shared or Standard?) If you can up the size of the instance to try and get things moving again more quickly.
I think you deployment is too slow. IIS detects changes in dll files and restart the app-pool automatically without waiting for the other dll files.
Try to set custom values in waitChangeNotification and maxWaitChangeNotification in web.config. Doing so you can ask IIS to wait for some seconds before restarting app-pool. I'm not sure if it works on Azure. On my on-premises IIS I use custom values that allow me to do a long deploy (about 5 seconds).
Documentation: http://msdn.microsoft.com/en-us/library/e1f13641(v=vs.85).aspx
I need to add some new entries to machine.config on a machine running SharePoint 2013 (server). However, no matter what change I make, after I have saved the file and restarted IIS (both steps are successful), all SharePoint sites return HTTP Error 503 ("Service Unavailable") when an attempt is made to view them in a browser on a client machine.
In Internet Information Services (IIS) Manager, it seems that the entire server becomes unavailable - no application pool or site can be accessed, i.e. trying to click anything returns "Filename:redirection.config / Error: Cannot read configuration file". This error goes away once the original machine.config is restored.
The machine.config file I'm trying to edit is located at:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config
Any help on how to resolve this would be appreciated.
Turns out you need to define <sectionGroup> elements in machine.config - I was not aware of that. E.g. if you want to use <Test> key somewhere, you need to add it to the appropriate section elsewhere in machine.config like this: <section name="Test" .../>. More info can be found on MSDN.
I have several sites running in IIS Express for the same project.
They are mapped to real domains via the host file, local.xxx.com etc. instead of localhost:XXX
I add a binding for https, under one site in the applicationhost.config file , but it is constantly removed, seemingly randomly by VS2012. Meaning, I add it. save it, and it works, then at some point in time later, VS2012 edits my applicationhost.config file and removes, just the https binding, leaving the http binding intact. It doesn't do this on all sites in the config, even if those sites are in the same solution. Just one site.
How do I make it stop?