Caveat With ASP.NET Precompilation and web.config Settings

When ASP.NET 2.0 compiles a web site, it reads the site’s web.config to pick up a few settings that affect the generated code. For instance, ASP.NET reads the <profile> section to generate the code for a Profile class with strongly typed properties.

What may not be intuitive at first is what happens with these web.config settings when the ASP.NET precompilation tool creates a “non-updateable” web site (a full precompilation). For instance, we can set a default theme and master page for the a site in web.config:

When performing a full precompilation, the ASP.NET compiler bakes the theme and master page settings into the generated code. This means if you go back and change the web.config to use Theme2 and MasterPage2, the settings won’t make a difference in a non-updateable web site. The site happily goes along using the web.config settings in effect when precompilation took place (Theme1, MasterPage1).

On one hand, the behavior makes sense, because we did ask for a non-updateable web site, right? On the other hand, we can change other areas (like a connection string or an authorization entry), and the website behaves differently. It’s just a case of knowing which settings are used during the parsing / compilation, and which settings are used at runtime.

If we want to specify the default theme in web.config, and use precompilation, and want the ability to switch the default theme in production, then there are still options.

The first option is to precompile to an updateable web-site. For a precompiled, updateable web site, the .aspx source code remains in tact and deployed. The ASP.NET runtime will regenerate code for the .aspx when the web.config setting changes.

A second option is to hook the Pre_Init event. Even on a non-updateable web site, the PreInit event can set the Theme and MasterPageFile properties of a form to override the web.config settings. The configuration API makes it easy to read any updated web.config settings.