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.
A Web. config transformation file contains XML markup that specifies how to change the Web. config file when it is deployed. You can specify different changes for specific build configurations and for specific publish profiles.
The web. config files specify configuration settings for a particular web application, and are located in the application's root directory; the machine. config file specifies configuration settings for all of the websites on the web server, and is located in $WINDOWSDIR$\Microsoft.Net\Framework\Version\Config.
In order to create the web. config transformations, locate the web. config file in the ASP.NET project, and right-click the item in the solution explorer. Notice the menu item “Add Config Transforms”.
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.
With the new VS you can use web config transformations.
Read more here: http://msdn.microsoft.com/en-us/library/dd465326.aspx
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With