I have noticed how editing the web.config file in an application folder causes that application pool to recycle and pick up the changes.
How does IIS achieve this and is it possible to extend this functionality for another config file? Or is this dependency hard-coded somewhere? This is related to the possiblity of deploying configuration changes to a web server without having to edit the web.config, which is usually maintained by a different team.
Note that I don't want to manually invoke this recycle event, but have it work in the same way as with web.config. I'm aware that I could simply add these settings to web.config, but that's not what I've been asked to do.
Many thanks,
Robin
Actually the application pool is not recycle, just rebuild the site.
...to extend this functionality for another config file?
Well, when you change and save the other config file you can call this command to make rebuild the site
HttpRuntime.UnloadAppDomain();
Related
We are using ASP.NET for our web application which is hosted in IIS 8.5. ASP.NET uses a web.config file to store all application and IIS related configurations. Whenever we deploy a new version of code for the web application, we also deploy the web.config file.
Recently the operation team has raised a concern to this deployment process. They say, if someone change some settings in IIS and for that web.config has been updated for that, there is no way for the developers to know that change so that they can update the web.config in codebase (version control system). So eventually at the time of next deployment the web.config changes will be overridden by the old web.config.
There are two possible solutions can be taken:
Merge the web.config with server and codebase before deploy the code everytime.
Decouple the application configuration and IIS configuration in different configuration files.
My question is, what is the best practice to solve these kinds of problems in ASP.NET?
IIS 7+ introduced its distributed configuration which allowed for IIS as well as .NET configuration to live inside of Site/App/Directory web.config files. One of the primary reasons for this is as follows: In IIS 6, whenever an application team needed to deploy their application and make changes to settings like Default Document, they needed the IIS team involved because "Default Document" was an IIS configuration setting. You could argue that Default Document settings for a particular application is not IIS configuration, but instead is Application configuration. As result, the Application Team should own that configuration setting and deploy it as part of the application.
A bit more about IIS7+ configuration system: Administrators are able to configure what settings are allowed to be set inside Web.config files. For example, by default, "Default Document" is able to be set inside Web.config files, and Authentication settings like Windows Authentication are not. The implementation can actually get complex, but if you'd like to read about it, you can see it here: https://learn.microsoft.com/en-us/iis/get-started/planning-for-security/how-to-use-locking-in-iis-configuration.
Ultimately the best practice is for IIS Administrators to configuration the settings they want Application teams to manage (by delegating those settings to Web.config) and then not touch them. In other words, if Default Document needs to be updated, then it is the Application Team's responsibility and they publish a new web.config file. If the IIS team decides they want to manage Default Document, then they need to lock down the IIS configuration system to prohibit Default Document from being managed in the web.config files.
If I modify an object on web.config that populates a combobox in a web application that is in a staging area or even production, do I need to restart the IIS or it detects that the web.config was changed?
Sorry for the silly question
Ty
Changes to configuration settings in Web.config files indirectly cause
the application domain to restart. This behavior occurs by design.
From MSDN
any change to the web.config will initiate a recycle of the application pool, you do not need to restart anything.
I am developing with VS2012 also it was same with VS2010. I working on a Web Application project. I have added a virtual application on IIS and set my project root folder as localhost/MyWebApp.
It often happens, when I do a simple page edit (on .aspx files) my site loses sessions. I am sure that no server side code is changed or no runat=server tag was affected.
How can I get rid of this?
Elaborating on David's comment:
File Change Notification
ASP.NET 2.0 depends on File Change Notifications (FCN) to see if the
application has been updated, and depending on the magnitude of change
the application pool will recycle. If you or your application are
adding and removing directories to the application folder, then you
will be restarting your application pool every time.
Altering the following files also causes an immediate restart of the
application pool:
web.config
machine.config
global.asax
Any file in the /bin directory or subfolders
Updating .aspx files, etc. causing a recompile eventually triggers a
restart of the application pool also. There is a property of the
compilation element under system.web called
numRecompilesBeforeAppRestart. The default value is 20, meaning that
after 20 recompiles the application pool will recycle.
Taken from: Losing ASP.NET Sessions - Why Application Pools recycle
Answer from Hans V:
When using the default SessionState Mode "InProc", you session will
be lost when the application pool recycles. Therer are many reasons
why this could happen, but also when you change aspx files:
ASP.NET depends on File Change Notifications (FCN) to see if the
application has been updated. Depending on the change the application
pool will recycle. If you or your application is adding and removing
directories to the application folder, you will be restarting your
application pool every time, so be careful with those temporary
files. Altering the following files will also trigger an immediate
restart of the application pool:
web.config
machine.config
global.asax
Anything in the bin directory or it's sub-directories
Updating the .aspx files, etc. causing a recompile will eventually
trigger a restart of the application pool as well. There is a
property of the compilation element under system.web that is called
numRecompilesBeforeAppRestart. The default value is 20. This means
that after 20 recompiles the application pool will recycle.
Answer reference
How do I take a backup of a site (and its settings) in IIS7 so that later if something goes wrong I can go back to my previous settings?
Updated:
I just want the settings, main website/sub- application, application pool etc. I can restore code from svn.
You can do the following:
%windir%\system32\inetsrv\appcmd.exe add backup "backup_name"
The above basically backs up %windir%\system32\inetsrv\config
You can also look into application config history: http://learn.iis.net/page.aspx/129/using-iis-70-configuration-history/
You probably want to start with (assuming a normal installation)
c:\windows\system32\inetsrv\config\applicationHost.config
as that's where the IIS config file is for websites.
There's not really the same "backup this site" like there was in IIS6, since they redid the underlying model.
If I add "trace=true" into my directive on an asp.net 2.0 .aspx page, will it recycle my application pool?
I know if I enable tracing in web.config that will recycle the application pool.
The webserver is IIS 6.0.
Thanks.
I'm not 100% sure but it shouldn't. Any change to a web.config file would cause an app pool reset, but a page level change shouldn't even in the directive.
Check out the section "Why does an application domain recycle?" in this link
Technically if it's the 15th re-compile it could cause a reset... but other than that no.
I believe it will just trigger a recompile of that page. Editing of an aspx file is not a trigger for an application restart.
Why not test it out and see?
Ok - I just tried it out on a testing server - adding in the "trace=true" directive on the page level did NOT recycle the application pool.
It won't. the app pool only recycles when a dll is changed in the Bin directory or if the web.config file is changed. If you are concerned about loosing your session info as that is what the question seems to me to be more related to then you can use the asp.net session state provider and that way your app pool can recycle as many times as it likes without you loosing your session.