One of common customer questions/requests I get is about industry best practices and recommendations on managing configuration file settings when deploying code across environments. 

 

There are several options to change different configuration settings in web.config file based on whether the application is in a DEV, QA, STAGE or PROD environment, and, based on my research, all of them rely on maintaining separate config files and/or configuration sections per each environment…

 

In my opinion, a better approach is outlined below…

 

 

1.    Create variables (or tokens) for items that vary across environments.  E.g. if in development, you use http protocol, but in test and production you use https, use a token like %protocol% instead

 

2.    Define the value of the tokens for each environment, e.g.

<token name="%protocol" devValue="http" testValue="https" prodValue="https" />

Here is a small example of what your config file might look like:

 

3.    Use the provided Add-In to create the correct configuration file for the chosen environment either on-demand:

 

or at build time:

If you don’t want this action to run every time you compile, simply select an empty (blank) entry from the Target Environment dropdown.  If the Target Environment drop down box is set to a non-empty value, the configuration tool will automatically run when a project/solution is built.

 

 

Note: you can customize this tool to use your environment names, e.g. instead of dev, test and prod, you may want to choose dev, qa, stage, prod…  Perfectly all right…  Just let the add-in know your preferences by modifying the TargetEnvironments:

 

 

 

To summarize, the add-in expects the following data:

 

·         Each .config file in a project should have a matching .target.config file.  For example, if you have web.config, you should also have web.target.config

·         Put all your configuration into the .target.config file, use tokens in places where replacements need to be made

·         Add <tokens> section, specifying the replacement values for the tokens for each target environment.  Make sure to add values for all environments, e.g. if you add Staging environment, add stagingValue replacement value.

 

To install the add-in:

 

1.    Copy ConfigAddIn.dll and ConfigAddIn.dll.config to the desired location

2.    Open ConfigAddIn.dll.config and set the TargetEnvironments to desired environments (e.g. replace Test with QA, add Staging, etc.)

3.    Open ConfigAddIn.AddIn and modify Assembly path to point to the location containing the add-in assembly

4.    Copy ConfigAddIn.AddIn to C:\Users\YOURLOGIN\Documents\Visual Studio 2008\Addins

5.    Launch Visual Studio.  You should now have a way to run the configuration tool on demand and at build time.

As always, standard disclaimer applies – provided as-is, sample code, use at your own risk, etc.  (I coded this in about a day… basically, quick-and-dirty POC)…

 

Your feedback and comments are always welcome and appreciated (actually, your comments are much needed elixir, the energy source that keeps me blogging).

 

 

[Aug 19, 2010]

A Visual Studio 2010 version is available at http://blogs.msdn.com/b/irenak/archive/2010/08/19/sysk-379-visual-studio-2010-add-in-for-managing-configuration-files-across-environments.aspx