Как управлять настройками конфигурации для каждого разработчика - PullRequest
3 голосов
/ 21 августа 2008

В проекте .NET, скажем, у вас есть параметр конфигурации - например, строка подключения - хранится в файле app.config, который отличается для каждого разработчика в вашей команде (они могут использовать локальный SQL Server или конкретный экземпляр сервера или использование удаленного сервера и т. д.).

Как вы можете структурировать свое решение так, чтобы каждый разработчик мог иметь свои собственные "предпочтения" разработки (то есть не проверенные в управлении исходным кодом), но предоставить строку соединения по умолчанию, которая проверяется в управлении исходным кодом (тем самым обеспечивая правильные значения по умолчанию для процесс сборки или новые разработчики).

<ч /> Редактировать: Может ли метод "file", предложенный @Jonathon, каким-то образом использоваться с секцией connectionStrings?

Ответы [ 5 ]

4 голосов
/ 21 августа 2008

AppSettings может быть переопределен локальным файлом:

<appSettings file="localoveride.config"/>

Это позволяет каждому разработчику сохранять свои локальные настройки.

Что касается строки подключения, то в идеальном мире все разработчики должны подключаться к тестовой БД, а не запускать SQL Server каждый.

Однако я считаю, что лучше всего сохранить файл с именем Web.Config.Prd в системе управления версиями и использовать его для развертываний сборок. Если кто-то изменяет web.config, он также должен добавить изменение в файл .PRD ... Там нет хорошей автоматизации: (

3 голосов
/ 21 августа 2008

Редактировать: может ли метод "файл" предложить @Jonathon каким-то образом используется с раздел connectionStrings?

Или вы можете иметь несколько строк подключения в файле config с проверкой и использовать ключ AppSettings, чтобы определить, какую ConnectionString следует использовать. Для этой цели в моей базе кода есть:

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;
    }
}
0 голосов
/ 21 августа 2008

Может ли метод "file", предложенный @Jonathon, каким-то образом использоваться с разделом connectionStrings?

Нет, но ничто не мешает вам сохранить ConnectionString как ключ AppSettings.

0 голосов
/ 21 августа 2008

Я использую довольно архаичный дизайн, который просто работает.

  • / _ Test__app.config
  • / _ Prod__app.config
  • / app.config

Затем в моем скрипте nant у меня есть задача, которая копирует текущую среду сборки плюс _ app.config и копирует ее в app.config.

Это неприятно, но вы не можете попасть между провайдерами и ConfigurationManager, чтобы подделать его, сказав, что провайдеры смотрят на строку подключения "dev" или "prod" и просто имеют 3 именованные строки подключения.

nant task:

<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>
0 голосов
/ 21 августа 2008

Я всегда делаю шаблоны для своих конфигурационных файлов.

В качестве примера я использую NAnt для построения своих проектов. У меня есть зарегистрированный файл с именем local.properties.xml.template. Моя сборка NAnt предупредит разработчика, если local.properties.xml не существует. Внутри этого файла будут настройки, специфичные для рабочей станции. Шаблон будет проверен в системе контроля версий, но фактическая конфигурация не будет.

...