Using the web.config file to manage application configuration settings is a great way to manage ASP.NET applications; however, managing web.config files within a multi-tiered can pose its own challenges.  Frequent solutions include maintaining multiple versions of the web.config file or placing environment specific settings within comments inside the web.config file, but an often overlooked method of managing the web.config file is to use the configSource attribute on environment specific sections of the file.

Method #1: Separate web.config Files

Creating copies of web.config files is one method of managing environment specific settings.  An environment configured in this manner may have files similar to these within the project:

• web.config
• web.config.dev
• web.config.live
• web.config.test
• web.config.live1
• web.config.live2

Since the file named web.config is always the file in use, the .config.extension files need to be renamed to web.config.  One of the problems with this method is that files are constantly renamed and it is easy to forget to update the .config.extension version since it is never being used directly.  Additionally, multiple web.config files need to be maintained, and this can lead to uncertainty over which file is up to date and whether the files are in synch.  This uncertainty can be magnified in a team environment where multiple developers may be making changes independently.

Method #2: Using Comments

Another method of managing environment specific settings is to create a single web.config file and store all settings for all environments as comments within the file.  Then the developer can uncomment or copy/paste the correct settings for the specific environment.  The problem with this method is that keeping track of all these settings can quickly become unmanageable and doing so is error prone.  Another issue with this is that it can become cumbersome if there are a lot of settings that need to be changed per environment.

Method #3: Using the configSource Attribute

The configSource attribute is available on all section elements within the web.config file.  This can be very very helpful for specifying environment specific configuration information within the web.config file.  An example site layout could look like the following when viewing in Visual Studio:

In the above example the appSettings and connectionStrings sections are externalized to environment specific configuration files.  Within the web.config file the following would be specified for the development environment:

<appSettings configSource="configuration\dev\appsettings.config"/>

<connectionStrings configSource="configuration\dev\datasource.config"/>

Using the configSource method, the web.config file should always remain the same for each environment, with the exception of dev/staging/live environment paths.  This simplifies deployments because all the files can be copied to each environment and the person performing the deployment only needs to update the configSource paths within the web.config file.  Multiple files still need to be maintained, but these files are generally much smaller than a single, monolithic web.config file.

Make sure to name files specified by the configSource with a .config extension.  Other extensions can be used, but they may also be servable via IIS, which would be a gaping security hole.  Make sure that an XML file extension is not used, this would leave the configuration settings completely unprotected from prying eyes.

Other section elements to consider externalizing:

• <customErrors />
• <identity />
• <smtp />
• <log4net />
  

Download example configSource site: tmproot.zip (3.88 kb)