Differentiating web.config between dev, staging and production environments

asp.netconfigurationdeploymentweb.config

Anyone have any good tips on handling differences in web.config settings between environments? I've considered creating a 'config' folder in our source control system but outside of the web hierarchy, and having the deployment process copy the appropriate config files (web.dev.config,web.staging.config, web.production.config) into the web folder upon deployment. I've also seen posts on how to programmatically change the config settings (WCF endpoints, connection strings, etc) when the app starts.

What are considered best practices here, and what experiences has everyone had with these or other approaches?

Update Sep 2010

It's worth noting that Visual Studio 2010 adds this ability via web.config transforms. When you use the build configuration manager (Build|Configuration Manager…) to create different configurations for your project (say, Debug, Dev, Staging and Release), VS adds web.*.config files to the solution. The default web.config contains baseline settings that you'll use for debugging. web.release.config, web.staging.config, etc contain XSLT transforms that will be applied whenever you publish your project based on the active build configuration.

Best Answer

My approach has been to have multiple config files. I put all environment agnostic stuff (i.e. doesn't matter if dev, staging, or production) in the web.config file. Anything that is specific to the environment (i.e. database connection info, logging, debug settings, etc.) I put into a local.config file specific to the environment. You can then include the local.config settings in the web.config using configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

Web.config can then be checked into source control. Don't check in the local.config files - that forces you to deploy the correct one in your deploy scripts.

Related Solutions

Visual-studio – Using different Web.config in development and production environment

In Visual Studio 2010 and above, you now have the ability to apply a transformation to your web.config depending on the build configuration.

When creating a web.config, you can expand the file in the solution explorer, and you will see two files:

Web.Debug.Config
Web.Release.Config

They contain transformation code that can be used to

Change the connection string
Remove debugging trace and settings
Register error pages

See Web.config Transformation Syntax for Web Application Project Deployment on MSDN for more information.

It is also possible, albeit officially unsupported, to apply the same kind of transformation to an non web application app.config file. See Phil Bolduc blog concerning how to modify your project file to add a new task to msbuild.

This is a long withstanding request on the Visual Studio Uservoice.

An extension for Visual Studio 2010 and above, "SlowCheetah," is available to take care of creating transform for any config file. Starting with Visual Studio 2017.3, SlowCheetah has been integrated into the IDE and the code base is being managed by Microsoft. This new version also support JSON transformation.

.net – Managing complex Web.Config files between deployment environments

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 effect is that developers can create different flavors and keep them under source control without affecting the "real" configs.

Best Answer

Related Solutions

Visual-studio – Using different Web.config in development and production environment

.net – Managing complex Web.Config files between deployment environments

Related Topic