Дифференцирование web.config между средами разработчиков, промежуточной и производственной среды

У кого-нибудь есть хорошие советы по обработке различий в настройках web.config между средами? Я подумал о создании папки "config" в нашей системе управления версиями, но за пределами веб-иерархии, а процесс развертывания копирует соответствующие файлы конфигурации (web.dev.config, web.staging.config, web.production.config ) в веб-папку после развертывания. Я также видел сообщения о том, как программно изменять настройки конфигурации (конечные точки WCF, строки подключения и т.д.), Когда приложение запускается.

Что считается наилучшей практикой здесь и какой опыт имеет каждый с этими или другими подходами?

Обновление сентябрь 2010

Стоит отметить, что Visual Studio 2010 добавляет эту способность через web.config преобразует. Когда вы используете диспетчер конфигурации сборки (Build | Configuration Manager...) для создания различных конфигураций для вашего проекта (скажем, Debug, Dev, Staging and Release), VS добавляет в решение файлы конфигурации. *. Config. По умолчанию web.config содержит параметры базовой линии, которые вы будете использовать для отладки. web.release.config, web.staging.config и т.д. содержат преобразования XSLT, которые будут применяться каждый раз, когда вы публикуете проект на основе конфигурации активной сборки.

Ответ 1

С новым VS вы можете использовать преобразования веб-конфигурации.

Подробнее здесь: http://msdn.microsoft.com/en-us/library/dd465326.aspx

Ответ 2

Мой подход состоял в том, чтобы иметь несколько конфигурационных файлов. Я помещаю все агностические элементы среды (т.е. Не имеет значения, если dev, постановка или производство) в файле web.config. Все, что является специфическим для среды (например, информация о подключении к базе данных, протоколирование, параметры отладки и т.д.), Я помещаю в файл local.config, специфичный для среды. Затем вы можете включить параметры local.config в файле web.config с помощью configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

Затем Web.config можно проверить в исходном элементе управления. Не проверяйте файлы local.config, что заставляет вас развернуть правильный код в сценариях развертывания.

Ответ 3

Я использую CruiseControl.NET/NAnt, а NAnt имеет задачу XMLPoke, которая позволяет вам работать, когда вы создаете и изменяете любой параметр конфигурации с помощью запросов XPath.

Итак, в каждой из моих целей построения (DEV, UAT, STAGING и т.д.) я устанавливаю кучу свойств, а затем вызываю главную цель сборки. Мастер-цель сборки принимает значения всех свойств и XMLPokes их в конфигурацию и сборки.

Ответ 4

Один из методов, который я видел и использовал, - это то, где вы устанавливаете ключи в своем web.config, чтобы различать компьютеры по имени.

Итак, например:

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

Очевидно, что comp1, compdb1 являются фактическими именами компьютеров.

Затем вы должны установить что-то вроде:

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

В вашем коде вам нужно будет проверить, в какой среде работает приложение, а затем получить соответствующий ключ, например.

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

Ответ 5

Существует проект типа Проект веб-развертывания, свободно доступный от Microsoft, который позволяет делать именно это. Вы можете заменить разделы вашего web.config, в зависимости от конфигурации вашего решения (отладка, выпуск и т.д.). Мы используем это более года и хорошо работаем. Он доступен для VS2005 и VS2008.

Надеюсь, это поможет

Ответ 6

В то время как некоторые другие ответы могут быть более подходящими, я просто добавлю, что Мэтт Берсет покатил свой собственный метод в 2007 году..

В итоге он сохраняет все значения, которые различаются между средами в собственном текстовом файле и использует встроенный инструмент во время процесса сборки для объединения значений в файлы .config.

В комментарии к этому сообщению Doron Yaacoby также комментирует:

"в сообществе MSBuild есть задание Задачи, которые могут достичь этого (и более) для вас, что называется XmlMassUpdate. Я написал об этом в своем блоге

Ответ 7

Здесь, как добавить различные конфигурации, которые могут быть настроены для ваших сред развертывания в VS2012

Щелкните правой кнопкой мыши по решению и выберите менеджер конфигурации
Нажмите кнопку "Диспетчер конфигурации"
В столбце "Конфигурация" выберите поле со списком для проекта что вы хотите добавить конфигурацию и выберите
Создайте новую конфигурацию с таким именем, как TEST и настройки копирования от версии и установите флажок "Создать новые конфигурации решений".
Щелкните правой кнопкой мыши по Web.config
Добавить конфигурационное преобразование
Затем вы получите дополнительный web.config Например web.TEST.config

После этого вам нужно изменить web.TEST.config с некоторыми преобразованиями, специфичными для вашей среды TEST

Ответ 8

Вам нужно УСТАНАВЛИВАТЬ для среды, а не BUILD для одного. В реальном мире вам нужно установить в prod то, что было проверено в QA, и никакая перестройка не разрешена. По крайней мере, в моем мире это дело.