SYSK 375: Visual Studio Add-In for Managing Configuration Files Across Environments
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
Comments
Anonymous
December 16, 2009
Unfortunately, I think this article paints a more simplistic view of the issue than it really is. In the SARBOX world where developers often cannot make any change between environments, the system needs to be able to identify what environment it is running in and load the appropriate configuration values at runtime. The second thing that needs to be more flexible is in how an environment is identified. It could be by machine address, name, a machine.config setting, windows domain etc. Third, as a local developer, I may need to override some random part of the configuration for local testing that might not otherwise change between environments, but I often don't want to do that by checking out the configuration which might result in an inadvertant check-in. In this scenario I need a true override rather than variables and I need the override to be specified in some local, non checked-in configuration file. Microsoft does a great job of coming up with extendable frameworks (ex. WCF). But in the case of configuration, there are comparatively few extension points and many of the classes used are closed (although I have not looked at .NET 4 yet). I want to be able to determine through an interface implementation, what constitutes an environment. I want to be able to determine exactly how the configuration is stored. I want to be able to have a pipeline of environment handlers that can determine, what if anything in the base configuration to change, and I want to be able to do it at runtime, if necessary.Anonymous
October 11, 2010
The comment has been removed