Como gerenciar as definições de configuração para cada desenvolvedor

Question

Em um projeto .NET, digamos que você tenha uma configuração - como uma string de conexão - armazenada em um arquivo app.config, que é diferente para cada desenvolvedor da sua equipe (eles podem estar usando um SQL Server local ou uma instância de servidor específica , ou usando um servidor remoto, etc.).

Como você pode estruturar sua solução para que cada desenvolvedor possa ter suas próprias “preferências” de desenvolvimento (ou seja,não verificado no controle de origem), mas fornece uma cadeia de conexão padrão que é verificada no controle de origem (fornecendo assim os padrões corretos para um processo de construção ou novos desenvolvedores).

---

Editar:Pode o "file"método sugerido por @Jonathon ser usado de alguma forma com o connectionStrings seção?

Answer 1

AppSettings pode ser substituído por um arquivo local:

<appSettings file="localoveride.config"/>

Isso permite que cada desenvolvedor mantenha suas próprias configurações locais.

No que diz respeito à cadeia de conexão, em um mundo perfeito, todos os desenvolvedores deveriam se conectar a um banco de dados de teste, e não executar o SQL Server cada um.

No entanto, achei melhor manter um arquivo chamado Web.Config.Prd no controle de origem e usá-lo para implantações de compilação.Se alguém modificar o web.config, ele também deverá adicionar a alteração ao arquivo .PRD... Não há uma boa automação aí :(

Answer 2

Editar:O método "Arquivo" sugerido por @jonathon pode ser usado de alguma forma com a seção Connectionstrings?

Ou você pode ter várias cadeias de conexão no arquivo de configuração verificado e usar uma chave AppSettings para determinar qual ConnectionString deve ser usado.Eu tenho o seguinte em minha base de código para essa finalidade:

public class ConnectionString
{
    public static string Default
    {
        get 
        { 
            if (string.IsNullOrEmpty(ConfigurationManager.AppSettings["DefaultConnectionStringName"]))
                throw new ApplicationException("DefaultConnectionStringName must be set in the appSettings");

            return GetByName(ConfigurationManager.AppSettings["DefaultConnectionStringName"]);
        }
    }

    public static string GetByName(string dsn)
    {
        return ConfigurationManager.ConnectionStrings[dsn].ConnectionString;
    }
}

Answer 3

Sempre faço modelos para meus arquivos de configuração.

Como exemplo utilizo o NAnt para a construção dos meus projetos.Tenho um arquivo com check-in chamado local.properties.xml.template.Minha compilação NAnt avisará o desenvolvedor se local.properties.xml não existir.Dentro desse arquivo estarão as configurações específicas da estação de trabalho.O modelo será verificado no controle de origem, mas a configuração real não será.

Answer 4

Eu uso um design bastante arcaico que simplesmente funciona.

• /_Test__app.config
• /_Prod__app.config
• /app.config

Então, em meu script nant, tenho uma tarefa que copia o ambiente de construção atual mais _ app.config e o copia para app.config.

É desagradável, mas você não pode entrar entre os provedores e o ConfigurationManager para falsificá-lo, dizendo que os provedores olham para a cadeia de conexão "dev" ou "prod" e têm apenas três cadeias de conexão nomeadas.

tarefa importante:

<target name="copyconfigs" depends="clean">
  <foreach item="File" property="filename" unless="${string::get-length(ConfigPrefix) == 0}">
   <in>
     <items>
       <include name="**/${ConfigPrefix}App.config" />
       <include name="**/${ConfigPrefix}connectionstrings.config" />
       <include name="**/${ConfigPrefix}web.config" />
     </items>
   </in>
   <do>
    <copy overwrite="true" file="${filename}" tofile="${string::replace(filename, ConfigPrefix,'')}" />
   </do>
  </foreach></target>

Answer 5

O método "arquivo" sugerido por @Jonathon pode ser usado de alguma forma com a seção connectionStrings?

Não, mas nada impede você de armazenar ConnectionString como uma chave AppSettings.