Управление сложными файлами Web.Config между средами развертывания - PullRequest
53 голосов
/ 09 января 2009

Кто-нибудь знает какие-либо хорошие инструменты / утилиты для управления файлами Web.Config между различными средами сборки / развертывания?

Например, у меня есть проект WCF, в разработке которого я не хочу включать SSL, но хочу, чтобы он был включен в производстве. Мне нужны разные настройки ведения журналов, разные строки подключения к БД, разная обработка ошибок, разные пути к файлам ... Даже некоторые разные привязки инфраструктуры Unity (связывание макетов для модульного тестирования вместо реальных объектов для развертывания).

Сохранять отдельные копии Web.Config очень сложно, поскольку добавление нового веб-сервиса означает редактирование нескольких файлов и их синхронизацию.

Я также заметил, что если вы гадите слишком много Web.Config вручную, Visual Studio захлебнется, если вы попытаетесь использовать мастер «добавления элемента», скажем, для добавления новой веб-службы для WCF, поскольку он должен изменить Web.Config, чтобы добавить конечную точку, и не может больше ее анализировать. Поэтому я должен быть осторожен, чтобы не сделать недействительным существующий Web.Config.

Я также думал о том, чтобы просто использовать регулярное выражение для замены и просто создать новый Web.Config в команде перед сборкой. Это кажется лучшим вариантом на данный момент ...

Есть еще идеи? Похоже, что это должно быть очень распространенной проблемой, поскольку Web.Config, вероятно, никогда не должно быть одинаковым между развертыванием разработки и производства.


Обновление:

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

Так что я могу сделать в каталоге:

WebConfig_All

<configuration>
  <configSections>
    ...
  </configSections>
  <system.web>
    ...
  </system.web>
</configuration>

connectionStrings_Debug

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...dev..." />
  </connectionStrings>
</configuration>

connectionStrings_Release

<configuration>
  <connectionStrings>
    <add name="connstr" connectionString="...prod..." />
  </connectionStrings>
</configuration>

Затем запустите инструмент командной строки и введите конфигурацию (Debug, Release, custom ...) И он объединит все файлы, которые заканчиваются на _All" or _ `.

Итак, теперь у меня есть 80% моего Web.Config в одном WebConfig_All файле и 20% пользовательского содержимого в отдельных файлах для каждой конфигурации сборки. Затем я могу запустить инструмент командной строки в качестве задачи перед сборкой в ​​VisualStudio, либо из NAnt, либо там, где я хочу ...

Я также сделал свою логику слияния XML достаточно хорошей, чтобы обрабатывать такие вещи, как:

<x>
  <y a="1">
    <z a="1"/>
  </y>
</x>

объединить с

<x>
  <y a="1">
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

Результат:

<x>
  <y a="1">
    <z a="1"/>
    <z a="2"/>
  </y>
  <y a="2"/>
</x>

Выглядит пока хорошо ...:)


Followup:

Эта тема немного устарела, поэтому я хотел отметить, что VisualStudio 2010 имеет встроенную функцию преобразования web.config: http://msdn.microsoft.com/en-us/vstudio/Video/ff801895

Конечно, в типичном для Microsoft способе реализовать любую функцию только на 50%, он работает только для веб-проектов, использующих веб-развертывание. Существует плагин для включения преобразований в других проектах, расположенный здесь: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx

Вы также можете использовать такой инструмент, как BuildMaster для управления файлами конфигурации (наряду со сборками, тестами, сценариями БД и т. Д.) *

Ответы [ 11 ]

20 голосов
/ 12 января 2009

Мы разделили все настройки, относящиеся к конкретному региону, в их собственный конфигурационный файл. Под корнем веб-приложения мы создаем папку конфигурации и помещаем туда настройки, специфичные для региона. Так что все файлы, которые живут в корне конфига, будут выбраны.

наш web.config выглядит примерно так:

.
.
.
<appSettings configSource="config\appSettings.config"/>
<nlog configSource="config\nlog.config"/>
<applicationSettings>
    <MyApp.UI.Properties.Settings configSource="config\Settings.APGUI.config"/>
    <MyApp.BusinessServices.Properties.Settings configSource="config\Settings.Business.config"/>
    <MyApp.Auditing.Properties.Settings configSource="config\Settings.Auditing.config"/>
</applicationSettings>
.
.
.

Таким образом, если мы выполняем развертывание в регионе выпуска, инструмент сборки будет просто выполнять действие, чтобы заменить файлы в корне конфигурации на файлы из соответствующей папки региона. Структура файла выглядит примерно так:

ДОБАВЛЕНО: Так выглядит структура управления исходным кодом, развернутое приложение будет просто иметь каталог config без подпапок или курса

\Root
   web.config    
   \Config    
       appsettings.config    
       services.config    
       logging.config    
       \release    
          appsettings.config    
          services.config    
          logging.config    
       \debug
          appsettings.config    
          services.config    
          logging.config

Он довольно чистый и поддерживается любым инструментом автоматической сборки (копирование / замена файлов). Приятным побочным эффектом является то, что разработчики могут создавать различные варианты и держать их под контролем исходного кода, не затрагивая «настоящие» конфиги.

7 голосов
/ 24 февраля 2009

Требуется задача XmlMassUpdate в MSBuildCommunityTasks (выполняет то, что вы пытаетесь сделать с помощью консольного приложения xml)

http://msbuildtasks.tigris.org/

используйте это так

  <XmlMassUpdate Condition=" '@(ConfigTemplateFile)'!='' And '@(ConfigSubstitutionsFile)'!=''"
    ContentFile="@(ConfigTemplateFile)"
    SubstitutionsFile="@(ConfigSubstitutionsFile)"
    MergedFile="@(ConfigFile)"
    ContentRoot="/configuration"
    SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>
7 голосов
/ 09 января 2009

Вы можете использовать Build Events для управления вашими веб-конфигами. У Хансельмана есть хорошая статья об этом.

В основном у вас есть все ваши различные web.configs в решении, которое вы затем создаете (некоторые) новые типы сборки. В зависимости от типа сборки, которую вы запускаете, web.config копируется поверх ссылочного!

4 голосов
/ 22 февраля 2009

Я использую этот инструмент: xmlpreprocess

мы поддерживаем отдельные файлы «свойств» для каждой среды, которые объединяются сценарием развертывания.

4 голосов
/ 09 января 2009

Я использую метод , объясненный Скоттом Хансельманом (он объясняет это намного лучше, чем я могу воспроизвести это, поэтому перейдите по ссылке :)) У меня все заработало ...

2 голосов
/ 11 апреля 2017

Старый вопрос, но, поскольку он имеет высокий рейтинг в поиске Google, я подумал, что было бы неплохо добавить синтаксис преобразования web.config , который доступен с VS2010, С помощью этого инструмента вы можете иметь разные файлы web.config для разных сборок (Debug / Release)

Вот краткое описание того, как иметь две строки подключения - одну для разработки (режим отладки) и одну для производства (режим выпуска):

1- Установите строку подключения к разработке в файле web.config. Должно выглядеть примерно так:

 <connectionStrings>
    <add name="myConnectionString"  connectionString="Data Source=TestDBServer; (etc...)" />
  </connectionStrings>

2- Разверните файл web.config и откройте web.release.config

web.config

3- Используйте функцию Replace , чтобы заменить строку подключения той, которую вы хотите использовать для производства. Вы можете использовать атрибут xdt:Locator="Match(name)", чтобы сопоставить его с именем строки подключения (myConnectionString) в этом примере:

<connectionStrings>
    <add name="myConnectionString"  xdt:Transform="Replace" xdt:Locator="Match(name)" 
         connectionString="Data Source=ProdDBServer; (etc...)" />
  </connectionStrings>

4 - Предварительный просмотр преобразования файла web.config, который будет использоваться во время сборки выпуска, щелкнув правой кнопкой мыши файл web.release.config и выбрав Предварительный просмотр преобразования .

enter image description here

2 голосов
/ 22 февраля 2009

Мы используем теги в наших конфигурационных файлах, которые заменяются во время сборки для отражения предполагаемой среды развертывания. Я был вдохновлен блогом Lavablast

Приятно иметь только один шаблонный файл для управления.

Недостатком является то, что вы не можете легко иметь пользовательские «разделы».

2 голосов
/ 09 января 2009

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

1 голос
/ 09 января 2009

Я традиционно использовал несколько web.configs, как вы упомянули. Это может быть болезненно, но это смягчается инструментами сравнения файлов, такими как BeyoneComapare2 или KDIff ...

0 голосов
/ 24 ноября 2016

Мои любимые два способа решения этой проблемы:

A. Сохраните настройки на целевом компьютере *. Например, в Azure вы можете настроить параметры приложения и строки подключения, которые будут переопределять значения в web.config. (* - или определение целевой машины, если конфигурация вашей инфраструктуры динамическая).

B. Сделайте так, чтобы инструмент сборки / развертывания (TeamCity, Octopus Deploy и т. Д., VS Team Services) вводил специфические для среды значения как часть сборки и / или внедрения. Современные инструменты поддерживают шифрование конфиденциальных настроек.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...