Background

This article details how to selectively recycle AppDomains in ASP.NET 1.x sites.  ASP.NET web sites are executed in the context of a worker process.  IIS 5 uses a single worker process (aspnet_wp.exe) for all web sites (assuming no web gardens) and IIS 6 users a worker process (w3wp.exe) for each application pool.  In order to provide separation between web sites that share a worker process, ASP.NET uses a new .NET concept called an AppDomain.  The AppDomain is a logical process that exists inside a worker process to provide isolation.  ASP.NET uses an AppDomain for each ASP.NET web site.  As an example, if you use IIS 5 with 3 ASP.NET web sites there will be a single worker process that contains 3 AppDomains.  The AppDomain stores the Application, Cache, and in-process Session objects for a site.  Sometimes it is necessary to recycle one of these AppDomains, preferrably without having to restart the worker process which would affect other AppDomains. 

Why Recycle?

Sometimes it is necessary to recycle a single AppDomain without impacting other ASP.NET sites on the same web server.  One example of this is when a web site uses a shared assembly (strong named assembly deployed to the Global Assembly Cache (GAC)) that has been updated.  When an application starts, the Common Language Runtime (CLR) binds to the the specific version of each assembly referenced in a project by default, but this can be altered through the use of configuration files or publisher policy files.  If a developer modifies a shared assembly and moves it to the GAC on the web server, the CLR will not start to use the new assembly even if configured to do so because once an application binds to an assembly it does not look for new updates each time it is used (for performance reasons). 

So how does the web site start to use the new assembly?  The AppDomain needs to be restarted.  It is possible to restart IIS or kill the worker process to get this to occur, but that is like using a sledgehammer to hang a picture--it works but does unneccesary damage to the surroundings.

Recycling an AppDomain

The method used here is to "touch" config files (machine.config or web.config) which will cause the AppDomain to recycle.  The touch is just an update of the last time the file was written without changing the file contents.  Touching the machine.config file will recycle all AppDomains on a server (for the specific version of .NET installed with that machine.config), while touching a web.config will just recycle that specific web site's AppDomain.  

A zip file is included that contains the source for the .NET console application that provides the touch functionality.  The program xx055.exe accepts paths to machine.config files (may be more than one if have more than one version of .NET installed), paths to web.config files, and other file system directory paths.  It will touch each specific config file provided.  When given a directory path, it will recursively touch a web.config file in that directory and all of its subdirectories.  The program by default logs an entry to the event log that details which files were touched.  This technique requires that the web.config files be writable so the last write time can be altered.  Warning:  Recycling an AppDomain will drop Application, Cache, and in-process Session information since that is stored in the AppDomain logical process! 

Conclusion

The ability to recycle a specific AppDomain for an ASP.NET web site provides a method to very selectively target a web site for restarts.  There are many times where this may prove useful, such as when shared assembly updates need to be loaded.  By "touching" the appropriate config files, the desired AppDomains can be restarted.

Send comments or questions to robertb@aspalliance.com.