Diferenciando web.config entre dev, teste e ambientes de produção

StackOverflow https://stackoverflow.com/questions/1406157

Pergunta

Alguém tem alguma boas dicas sobre gestão das diferenças na configurações web.config entre ambientes? Eu considerei a criação de um 'config' pasta no nosso sistema de controle de origem, mas fora da hierarquia de web, e ter copiar o processo de implantação os arquivos de configuração apropriados (web.dev.config, web.staging.config, web.production.config ) para a pasta de teia aquando do desdobramento. Eu também vi posts sobre como alterar programaticamente as definições de configuração (endpoints WCF, cadeias de conexão, etc) quando o aplicativo é iniciado.

O que são consideradas as melhores práticas aqui, e que experiências tem todos tinham com estas ou outras abordagens?

Atualização setembro 2010

É importante notar que o Visual Studio 2010 adiciona essa capacidade através de web.config transforma . Quando você usar o gerenciador de configuração de compilação (criação | Configuration Manager ...) para criar configurações diferentes para o seu projeto (digamos, Debug, Dev, estadiamento e Release), VS acrescenta web * arquivos de configuração à solução... O web.config padrão contém configurações de linha de base que você vai usar para depuração. web.release.config, web.staging.config, etc conter as transformações XSLT que serão aplicadas sempre que você publicar seu projeto com base na configuração de compilação ativa.

Foi útil?

Solução

Com o novo VS você pode usar transformações de configuração web.

Leia mais aqui: http://msdn.microsoft.com/en- us / library / dd465326.aspx

Outras dicas

A minha abordagem tem sido a de ter vários arquivos de configuração. Eu coloquei todo o material agnóstico ambiente (ou seja, não importa se dev, estadiamento, ou de produção) no arquivo web.config. Tudo o que é específico para o ambiente (ou seja, banco de dados informações de conexão, registro, configurações de depuração, etc.) Eu coloquei em um arquivo local.config específico para o ambiente. em seguida, você pode incluir as definições local.config no web.config usando configSource ( http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx )

Web.config pode então ser verificado no controle de origem. Não verificar nos arquivos local.config -. Que o obriga a implantar o correto em seus scripts Implantar

Eu uso CruiseControl.NET/NAnt e NAnt tem uma tarefa XMLPoke que lhe permite ir em como você está construindo e alterar a configuração usando consultas XPath qualquer configuração.

Assim, em cada uma das minhas metas de construção (DEV, UAT, estadiamento etc) eu definir um monte de propriedades e, em seguida, chamar o alvo mestre de construção. O alvo mestre de construção leva os valores de todas as propriedades e XMLPokes-los na configuração e constrói.

Um método que eu tenho visto e usado é onde chaves de instalação dentro de seu web.config para diferenciar os computadores pelo nome.

Assim, por exemplo: 

<add key="comp1.Environment"       value="DEV"/>
<add key="compdb1.Environment"     value="PROD"/>
<add key="compstage.Environment"    value="STAGE"/>

Obviamente comp1, compdb1 são os nomes dos computadores reais.

Você, então, configuração algo como: 

<add key="KeyName,DEV"   value="DevEnvironmentValue"/>

Em seu código, você precisa verificar o ambiente do aplicativo é executado em e, em seguida, pegar a chave apropriada, assim, por exemplo. 

private string GetKeyValue() {
    string machineName  = String.Concat(System.Environment.MachineName, ".Environment");
    string environment  = ConfigurationManager.AppSettings[machineName];
    string key          = String.Concat("KeyName", ",", environment);
    string keyValue       = ConfigurationManager.AppSettings[key];

    return keyValue;
}

Há um tipo de projeto chamado implantação da web projeto , livremente disponíveis da Microsoft que permitem que você faça exatamente isso. Você pode substituir seções do seu web.config, dependendo da sua configuração da solução (debug, solte etc.) Usamos que há mais de um ano e funciona bem. Ele está disponível para VS2005 e VS2008.

Esperamos que isto ajude

Enquanto algumas das outras respostas podem ser mais adequados Vou apenas acrescentar que Matt Berseth rolou seu próprio método volta em 2007 ...

Em resumo, ele mantém todos os valores que variam entre os ambientes em um arquivo de texto proprietária e usa uma ferramenta personalizada durante o processo de construção para mesclar os valores nos arquivos .config.

Em um comentário sobre esse post Doron Yaacoby também comenta:

"não é uma tarefa em MSBuild Comunidade Tarefas que podem conseguir isso (e mais) para você, que é chamado XmlMassUpdate. Ive escrito sobre isso no meu blog "

Veja como adicionar diferentes configurações que podem ser personalizadas para seus ambientes de implantação no VS2012

  1. clique direito do mouse no gerenciador de solução e selecione configuração
  2. Clique no botão Configuration Manager
  3. Na coluna Configuração seleccionar caixa de combinação contra o projeto que você deseja adicionar uma configuração de e Select
  4. Crie uma nova configuração com um nome como TEST e copiar configurações de lançamento e verificar a criar novas configurações de solução caixa de seleção
  5. clique direito do mouse no Web.config
  6. Adicionar Configuração Transform
  7. Em seguida, você recebe um web.config adicional Ex web.TEST.config

Após isso, você precisa modificar web.TEST.config com algumas transformações específicas para o seu ambiente de teste

Você precisa instalar em um ambiente, não BUILD para um. No mundo real, você tem que instalar em prod o que foi testada em QA, nenhuma reconstrução permitido. Pelo menos no meu mundo que é o caso. 

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

}

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top