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

Ответ 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, и никакая перестройка не разрешена. По крайней мере, в моем мире это дело.