Differentiating web.config between dev, staging an

Question

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.

Answer 1

While some of the other answers may be more suitable I'll just add that Matt Berseth rolled his own method back in 2007...

In summary he keeps all the values that vary between environments in a proprietary text file and uses a custom tool during the build process to merge the values into the .config files.

In a comment on that post Doron Yaacoby also comments:

"there is a task in MSBuild Community Tasks that can achieve this (and more) for you, which is called XmlMassUpdate. Ive written about it in my blog"

Answer 2

You need to INSTALL for an environment, not BUILD for one. In the real world, you have to install in prod what was tested in QA, no rebuilding allowed. At least in my world that's the case.

Answer 3

 Easy way to have that is having an Enumeration , then having a switch statement based on the server name ( if its stable name ) .  
 Call GetURIPath() where ever you require to fetch details , here I given the examples for url's used 


public class StaticData
{
    public enum enumEnvironment
    {
        envNONE = 0,
        envLOC = 1,
        envDEV = 2,
        envTEST = 3,
        envPROD = 4
    }
     private static enumEnvironment GetCurrentEnv()
    {
        if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null)
        {
            return enumEnvironment.envLOC;
        }
        else
        {
            NameValueCollection NVCollection = new NameValueCollection();
            NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings");
            if(NVCollection == null)
            {
                NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings");
            }

            string sEnv = NVCollection.GetValues("serverrole").ToString();

            switch (sEnv.ToUpper())
            {
                case "DEV-ISOLATED":
                    return enumEnvironment.envDEV;
                case "DEVELOPMENT":
                    return enumEnvironment.envDEV;
                case "TEST":
                    return enumEnvironment.envTEST;
                case "PRODUCTION":
                    return enumEnvironment.envPROD;
                default:
                    return enumEnvironment.envNONE;
            }
        }
    }
   public static string GetURIPath()
    {
        switch (GetCurrentEnv())
        {
            case enumEnvironment.envPROD:
                return "http://produrl/yourapp/api/";
            case enumEnvironment.envTEST:
                return "http://testurl/yourapp/api/";
            case enumEnvironment.envDEV:
                return "http://devurl/yourapp/api/";
            default:
                return "http://localhost/yourapp/api/";
        }
    }

}