Дифференциация web.config между dev, подготовка и продуктивными средами

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

Итак, в каждой из моих целей сборки (DEV, UAT, ЭТАП и т. Д.) Я устанавливаю кучу свойств, а затем вызываю главную цель сборки. Основная цель сборки принимает значения всех свойств и XML помещает их в конфигурацию и выполняет сборку.

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

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

Один метод, который я видел и использовал, - это установка ключей в файле 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;
}

Мой подход заключался в том, чтобы иметь несколько файлов конфигурации. Я помещаю все, что не зависит от среды (т.е. не имеет значения, является ли разработка, подготовка или производство) в файл 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 - это заставит вас развернуть правильный файл в сценариях развертывания.

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

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

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

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