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

StackOverflow https://stackoverflow.com/questions/1406157

Вопрос

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

Это было полезно?

Решение

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

Подробнее читайте здесь: http://msdn.microsoft.com/en- нас / библиотека / dd465326.aspx

Другие советы

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

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

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

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

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

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

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

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

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

  

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

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

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

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

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

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

    }

    Лицензировано под: CC-BY-SA с атрибуция
    Не связан с StackOverflow
    scroll top