In my last post I talked about how you can share a single config file among multiple project in a solution.  One of the feedback comments I got was how to have a single config file for multiple developers or even multiple environments.  So, today I thought I would chat about the different ways to handle this clumsy situation.

Scenario Overview

You have the standard app.config or web.config file and it holds values for your application.  But some of the config properties are either user specific (such as file path for local storage) or are environment specific (such as db connections, web services paths, etc).  When we deploy the application we need to ensure that the correct values are used, and we want to it with the least amount of friction.  The good news is there are many ways to skin this preverbal cat.

Option One -- Works, but is lame and painful

Probably the most common solution to this problem is also the most painful.  Simply have users 'hijack' the config file locally and modify their values.  Or when you deploy your code to another environment, you hand edit the file. 

Although this way works, it is lame and very, very error prone.  If a developer accidentally checks in his (or her) 'hijacked' copy they can then foobar others on the development team.  Or worse yet, you deploy your code and forget to change a value on in production and something really bad and painful happens.

Keep in mind one thing.  Manual processes are very error prone, avoid at all costs.

Option Two -- Getting better, but still not great

Another way that I have seen this problem solved is having multiple 'key' values in the config file.  Most of the time these values are distinguished by some sort of prefix on the key (note: there are other ways as well).   An example of this would be:
<add key="SomeQualifierHere.SomeRealKeyValue" value="SomeValue"/>

This method works, but is sloppy.  Now you have to add logic to your config file reader (please, please, please for the love of all things good, do not access your app.config file directly in your application.  Abstract that away into some class that handles this for you) to determine what 'environment' you are in and grab the right key/value pair.  The biggest issue with this method is that you add a ton of noise to the config file and you have to be very cautious when you deploy to new environments.

Option Three --  The best way

The best way that I have seen is to have a single config file, but multiple external mini-configs for each user.  This can be accomplished by using the configSource attribute items such as <connectionStrings> or <appSettings>.  This allows you to have your config file point to a single external mini-config that may be different for each user or environment.

Using the external config files you can setup either post-build events in the IDE or build actions on your build server to copy/rename/move the correct file as needed.

Because this actual topic has been talked about before in great detail, I am not going to rehash it here, instead I will point you towards 2 good resources I have used.

• http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
• http://weblogs.asp.net/bsimser/archive/2007/01/03/handling-multiple-environment-configurations-with-net-2-0.aspx

I hope this helps everyone,

Till next time,