How do you handle multiple web.config files for multiple environments?

The way I currently handle this is by having multiple config files such as:

web.config
web.Prod.config
web.QA.config
web.Dev.config

When the project gets deployed to the different environments I just rename the corresponding file with the correct settings.

Anyone have suggestions on how to handle this better?

EDIT:
Here are some of the things that change in each config:

• WCF Client Endpoint urls and security
• Custom Database configs
• Session connection strings
• log4net settings

Answers:

Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.

Method 1

Scott Gu had an article on this once. The solution he presented was to use a Pre-build event to copy the correct config into place depending on the build configuration chosen.

I also noticed that there already is a similar question here on SO.

Method 2

Transforms seem really helpful for this. You can replace certain sections with different rules.

http://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx

Method 3

The way we’ve been doing it is to override the AppSettings section:

<appSettings file="../AppSettingsOverride.config">
    <add key="key" value="override" />    
    ...
</appSettings>

This only works for the appSettings section and so is only useful to a degree. I’d be very interested in more robust solutions.

Edit Below

Just watched this:
http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

VS2010 has config transforms which look pretty awesome, should make multiple configurations a complete breeze.

Method 4

In Visual Studio, I create xcopy build events and I store all the config files in a /config folder. You only need one event for all configurations if you name your files after the build configuration: i.e. overwriting web.config with /config/web.$(Configuration).config

Method 5

My favorite way to tackle this is with the configSource attribute. Admittedly I only use this on one element (<connectionStrings>) but it does provide an easy way to swap in and out different segments of a web.config (which I do during install time via a WebSetup project).

Method 6

I also use the web.DEV.config, web.TEST.config, web.PROD.config etc.

I find this way the most easiest, simplest and straight-forward way if your projects are not complex. I don’t like making things more complicated than neccessary.

However, I have used NAnt and I think it works well for this. You can set up builds for your different environments. NAnt takes some reading to learn how to use it but it’s pretty flexible.

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

I used it along with CruiseControl.net and NUnit to perform automatic daily builds with unit test validation and thought they worked well together.

Method 7

It really depends on what the difference is between the environments that is causing you to use different web.config files. Can you give more information as to why each environment currently needs a different one?

Method 8

We have a few workarounds (not all of them are done with web.config but the same idea)

1. We include multiple configuration files in the packaged deployment. During installation we specify environment that we are installing on.
2. Migrate all environment specific settings to the Database server for that environment. WebServer provides its environment when requesting server name
3. Provide multiple settings (1 per environment) and using code request different settings.
4. Combination of 2 and 3 (Override a part of the settings based on the environment – for example application server name)

Method 9

Through most different version management software (subversion, git, etc) you can ignore specific files.

Thus, in subversion, I’d have:

configure.template.php – This file is versioned and contains templated configuration data, such as empty DSN’s
configure.php – This file is ignored, so that changes to it do not get tracked.

In subversion, the way to do this is:

svn pe svn:ignore .
It’ll open your editor, then you type
configure.php

Save, exit, checkin your changes, and you’re good to go.

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0