Разграничение web.config между разработкой, подготовкой и производственной средой

Question

У кого-нибудь есть хорошие советы по обработке различий в настройках 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 и Release), VS добавляет файлы web. *. Config в решение. Файл web.config по умолчанию содержит базовые параметры, которые вы будете использовать для отладки. web.release.config, web.staging.config и т. д. содержат XSLT-преобразования, которые будут применяться всякий раз, когда вы публикуете свой проект на основе активной конфигурации сборки.

Answer 1

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

Answer 2

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

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

Answer 3

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

Вы должны установить для среды, а не для одной. В реальном мире вы должны установить в prod то, что было протестировано в QA, пересборка не разрешена. По крайней мере, в моем мире это так.

Answer 9

 Easy way to have that is having an Enumeration , then having a switch statement based on the server name ( if its stable name ) .  
 Call GetURIPath() where ever you require to fetch details , here I given the examples for url's used 


public class StaticData
{
    public enum enumEnvironment
    {
        envNONE = 0,
        envLOC = 1,
        envDEV = 2,
        envTEST = 3,
        envPROD = 4
    }
     private static enumEnvironment GetCurrentEnv()
    {
        if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null)
        {
            return enumEnvironment.envLOC;
        }
        else
        {
            NameValueCollection NVCollection = new NameValueCollection();
            NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings");
            if(NVCollection == null)
            {
                NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings");
            }

            string sEnv = NVCollection.GetValues("serverrole").ToString();

            switch (sEnv.ToUpper())
            {
                case "DEV-ISOLATED":
                    return enumEnvironment.envDEV;
                case "DEVELOPMENT":
                    return enumEnvironment.envDEV;
                case "TEST":
                    return enumEnvironment.envTEST;
                case "PRODUCTION":
                    return enumEnvironment.envPROD;
                default:
                    return enumEnvironment.envNONE;
            }
        }
    }
   public static string GetURIPath()
    {
        switch (GetCurrentEnv())
        {
            case enumEnvironment.envPROD:
                return "http://produrl/yourapp/api/";
            case enumEnvironment.envTEST:
                return "http://testurl/yourapp/api/";
            case enumEnvironment.envDEV:
                return "http://devurl/yourapp/api/";
            default:
                return "http://localhost/yourapp/api/";
        }
    }

}