Differentiating web.config between dev, staging and production environments

user_135769 0
Viewed 24478

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.

deployment web-config configuration asp.net
9 Answers

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.

user_2296740

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"

rohancragg_53510

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 give 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/";
        }
    }
}
user_64894730
Related