Usando Web.config diferente no ambiente de desenvolvimento e produção

Eu preciso usar seqüência de conexão de database diferente e endereço do servidor SMTP no meu aplicativo ASP.NET dependendo de ele é executado em desenvolvimento ou ambiente de produção.

O aplicativo lê as configurações do arquivo Web.config por meio da propriedade WebConfigurationManager.AppSettings .

Eu uso o comando Build / Publish para implantar o aplicativo no servidor de produção via FTP e, em seguida, replace manualmente o Web.config remoto com o correto.

É possível de alguma forma simplificar o processo de implantação? Obrigado!

    No Visual Studio 2010 e acima, agora você pode aplicar uma transformação ao seu web.config, dependendo da configuração da compilation.

    Ao criar um web.config, você pode expandir o arquivo no gerenciador de soluções e verá dois arquivos:

    • Web.Debug.Config
    • Web.Release.Config

    Eles contêm código de transformação que pode ser usado para

    • Alterar a cadeia de conexão
    • Remover rastreio e configurações de debugging
    • Registrar páginas de erro

    Consulte Sintaxe de Transformação Web.config para Implantação de Projeto de Aplicativo da Web no MSDN para obter mais informações.

    Também é possível, embora sem suporte oficial, aplicar o mesmo tipo de transformação a um arquivo app.config não seja de aplicativo da Web. Veja o blog Phil Bolduc sobre como modificar seu arquivo de projeto para adicionar uma nova tarefa ao msbuild.

    Este é um longo pedido de suporte no Visual Studio Uservoice .

    Uma extensão para o Visual Studio 2010 e superior, ” SlowCheetah “, está disponível para cuidar da criação de transformação para qualquer arquivo de configuração. A partir do Visual Studio 2017.3, o SlowCheetah foi integrado ao IDE e a base de código está sendo gerenciada pela Microsoft. Esta nova versão também suporta transformação JSON.

    A tag no web.config suporta um atributo de arquivo que carregará uma configuração externa com seu próprio conjunto de valores / chaves. Estes irão replace quaisquer configurações que você tenha no seu web.config ou adicionar a elas.

    Aproveitamos isso modificando nosso web.config no momento da instalação com um atributo de arquivo que corresponde ao ambiente no qual o site está sendo instalado. Fazemos isso com um interruptor no nosso instalador.

    por exemplo;

        

    Nota:

    • Alterações no .config especificadas pelo atributo não acionarão uma reboot do processo de trabalho do asp.net

    Você já olhou para projetos de implantação da web?

    http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

    Existe uma versão para VS2005 também, se você não estiver em 2008.

    Eu gostaria de saber também. Isso ajuda a isolar o problema para mim

     
    

    Eu, então, manter um connectionStrings.config, bem como um “{host} connectionStrings.config”. Ainda é um problema, mas se você fizer isso para seções que diferem nos dois ambientes, você pode implantar e fazer a versão do mesmo web.config.

    (E eu não uso VS, btw.)

    Eu uso um script NAnt Build para implantar em meus diferentes ambientes. Eu tenho que modificar meus arquivos de configuração via XPath, dependendo de onde eles estão sendo implantados e, em seguida, automagicamente coloca-los nesse ambiente usando Beyond Compare .

    Leva um minuto ou dois para configurar, mas você só precisa fazer isso uma vez. Então arquivos em lote assumem enquanto eu vou pegar outra xícara de café. 🙂

    Aqui está um artigo que eu encontrei nele.

    Em um projeto em que tivemos 4 ambientes (desenvolvimento, teste, preparação e produção), desenvolvemos um sistema no qual o aplicativo selecionou a configuração apropriada com base no nome da máquina em que foi implantado.

    Isso funcionou para nós porque:

    • os administradores poderiam implantar aplicativos sem envolver desenvolvedores (um requisito) e sem ter que mexer com arquivos de configuração (que eles odiavam);
    • nomes de máquinas aderiram a uma convenção. Nós combinamos nomes usando uma expressão regular e implantamos em várias máquinas em um ambiente; e
    • Usamos segurança integrada para seqüências de conexão. Isso significa que poderíamos manter os nomes das contas em nossos arquivos de configuração em tempo de design sem revelar senhas.

    Funcionou bem para nós neste caso, mas provavelmente não funcionaria em todos os lugares.

    O editor de configuração da Biblioteca Corporativa pode ajudá-lo a fazer isso. Ele permite que você crie um arquivo de configuração base e, em seguida, deltas para cada ambiente. Em seguida, você pode mesclar a configuração base e o delta para criar um web.config específico do ambiente. Dê uma olhada nas informações aqui que o conduzem melhor do que eu.

    Você também pode fazer uma etapa de pós-compilation. Configure uma nova configuração que seja “Implantar”, além de Depurar e Liberar, e depois faça com que a etapa de pós-compilation copie o web.config correto.

    Usamos compilações automatizadas para todos os nossos projetos e, com elas, o script de construção atualiza o arquivo web.config para apontar para o local correto. Mas isso não ajudará se você estiver fazendo tudo do VS.

    Esse é um dos grandes benefícios de usar o machine.config. No meu último trabalho, tivemos ambientes de desenvolvimento, teste e produção. Nós poderíamos usar o machine.config para coisas como strings de conexão (para o apropriado, dev / test / prod SQL machine).

    Isso pode não ser uma solução para você se você não tiver access à máquina de produção real (como se estivesse usando uma empresa de hospedagem em um host compartilhado).