title: Differentiating web.config between dev, staging and production environments
body: <p>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.</p>
  <p>What are considered best practices here, and what experiences has everyone had with these or other approaches?</p>
  <p><strong>Update Sep 2010</strong></p>
  <p>It's worth noting that Visual Studio 2010 adds this ability via <a href="https://web.archive.org/web/20120621010228/http://blogs.msdn.com:80/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx" rel="nofollow noreferrer">web.config transforms</a>. 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.</p>