Managing complex Web.Config files between deployment environments

Question

Does anyone know of any good tools/utilities for managing Web.Config files between different build/deployment environments?

For example, I have a WCF pr

Answer 1

Old question, but since it's having a high rank in Google search, I thought it's a good idea to add the web.config transformation syntax, that has been available since VS2010. With this tool, you can have different web.config files for different builds (Debug/Release)

Here is a short summary on how to have two connections strings - one for development (Debug mode) and one for production (Release mode):

1- Set your development connection string in the web.config file. Should look similar to this:

 <connectionStrings>
    <add name="myConnectionString"  connectionString="Data Source=TestDBServer; (etc...)" />
  </connectionStrings>

2- Expand your web.config file and open web.release.config

3- Use the Replace function to replace the connection string with the one for you want for production. You can use xdt:Locator="Match(name)" attribute to match it with the name of the connection string (myConnectionString) in this example:

<connectionStrings>
    <add name="myConnectionString"  xdt:Transform="Replace" xdt:Locator="Match(name)" 
         connectionString="Data Source=ProdDBServer; (etc...)" />
  </connectionStrings>

4- Preview the transform of the web.config file that will be used during release build by right clicking on the web.release.config file and choosing Preview Transform.

Answer 2

You could use Build Events to manage your web configs. Hanselman has a good article about it.

Basically you have all your different web.configs in the solution you then create (some) new build types. Depending on the build type you run a web.config is copied over the referenced one!

Answer 3

We split out all region specific settings into thier own config file. Under the root of the web app we create a config folder and place the region specific settings there. So whatever files are living under the root of config will get picked up.

our web.config looks something like:

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
    <MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
    <MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
    <MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

So if we are deploying to the release region the build tool will just have an action to replace the files in the root of config with the files from the appropriate region folder. The file structure looks something like:

ADDED: This is how the source control structure looks, the deployed app would just have the config dir with no sub folders or course

\Root
   web.config    
   \Config    
       appsettings.config    
       services.config    
       logging.config    
       \release    
          appsettings.config    
          services.config    
          logging.config    
       \debug
          appsettings.config    
          services.config    
          logging.config

It is pretty clean and supported by any automated build tool(copying/replacing files). The nice side affect is that developers can create different flavors and keep them under source control without affecting the "real" configs.

Answer 4

I like to use a build task to automate changing the config file for the desired environment.

Answer 5

I use this tool: xmlpreprocess

we maintain separate 'property' files for each environment that are merged in by the deployment script.