How is new version of an ASPX file compiled and loaded into the application?

Question

Upon serving a request for an ASPX page, if ASP.NET notices any change to that page, it will automatically recompile the page into an assembly and use that new page definition to handle to the request.

As far as I know, .NET doesn't allow us to unload an assembly from an application domain. However, it does allow us to unload the whole application domain (with its assemblies). Therefore, it seems to me that the only way ASP.NET can replace the old assembly with the new assembly (of the updated ASPX file) is unloading the whole application domain and create a new one to host the web application (which is effectively a application restart, which happens when the web.config is changed, assemblies bin folder are updated etc.) However, I notice that it seems not to be the case as the application responds much more quickly after I modify an ASPX file than when I modify the web.config file.

Therefore, my question is: is it possible for ASP.NET to load new version of the assembly of an ASPX page without having to unload the whole application and create a new one?

Answer 1

Steve's answer is largely accurate, though the behaviour described (assembly generation on file changes) is predicated on the default CompilationMode=Always; you can avoid assembly generation all together with CompilationMode=Never. As an aside, note that there is also a new attribute available in 3.5, though it relates specifically to top-level changes that would have previously re-started the application (like web.config):

By default, when any change is made to a top-level file in a Web site, the whole site is recompiled. Top-level files include the global.asax file and all files in the bin and App_Code folders. It is safest to recompile everything when one of these files changes because other files in the site, such as .aspx and .ascx files, may reference the objects created by code in top-level files.

While recompiling everything works fine for most applications, it could cause a very large application to be unavailable for long periods of time even when minor changes have been made to it. If the application is large enough, it could be unavailable for five to ten minutes or more after a change is made.

If you want to be able to change top-level files without causing the whole site to be recompiled, you can set the optimizeCompilations attribute of the compilation element in the Web.config file to true.

Answer 2

ASP.NET can't unload the old assembly without the restarting the application, but it can ignore the old assembly and start using the newly compiled version of your page. A new assembly is compiled and loaded (actually containing the whole folder rather than just the one changed page) and subsequent requests use that new assembly.

You can see the change of assembly by writing out the assembly name in your page:

<%= System.Reflection.Assembly.GetExecutingAssembly().FullName %>

With two pages in different folders you'll see that the changed page moves to a new assembly, while the other page is unaffected.

To avoid gradually filling up memory with old assemblies, the application will occasionally be restarted in response to a change. By default this is every 15 changes, though you can adjust that in web.config with

<compilation debug="false" numRecompilesBeforeAppRestart="50" ...

Answer 3

ASP.NET compute hashes of your files and when they changes it recompile them

and since .net can't unload assemblies without unloading entire appdomain asp.net cannot do it too