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

Question

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 th

Answer 1

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).

Answer 2

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.

Answer 3

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)

Answer 4

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?

Answer 5

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

Answer 6

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.