Управление сложной сетью.Файлы конфигурации между средами развертывания
кто-нибудь знает какие-либо хорошие инструменты/утилиты для управления Web.Config файлы между различными средами сборки / развертывания?
например, у меня есть проект WCF, который в разработке я не хочу включать SSL, но я хочу, чтобы он был включен в производстве. Мне нужны разные настройки ведения журнала, разные строки подключения к БД, разная обработка ошибок, разные пути к файлам... Даже разные платформы Unity привязки (провода вверх глумится для модульного тестирования, а не реальный объекты для развертывания).
ведение отдельных копий Web.Config это боль, потому что добавление нового веб-сервиса означает редактирование нескольких файлов и их синхронизацию.
Я также заметил, что если вы гадите с Web.Config слишком много вручную, Visual Studio задохнется, если вы попытаетесь использовать мастер "добавить элемент", чтобы, скажем, добавить новую веб-службу для WCF, так как он должен изменить веб.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% моей сети.Конфигурация в одном WebConfig_All file, и 20% custom материал в отдельных файлах для каждой конфигурации сборки. Затем я могу запустить свой инструмент командной строки в качестве задачи предварительной сборки в 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>
выглядит хорошо до сих пор... :)
продолжение:
эта тема немного устарела, поэтому я хотел чтобы указать, что VisualStudio 2010 имеет функцию, чтобы сделать веб.встроенные преобразования конфигурации:http://msdn.microsoft.com/en-us/vstudio/Video/ff801895
конечно, в типичном способе Microsoft только реализации любой функции 50% пути, он работает только для веб-проектов с использованием веб-развертывания. Есть плагин для включения преобразований в других проектах, расположенный здесь: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx
вы также можете использовать такой инструмент, как BuildMaster для управления конфигурационными файлами (наряду со сборками, тестами, скриптами БД и т. д...)
11 ответов:
мы разделили все региональные настройки на свой собственный конфигурационный файл. В корневом каталоге веб-приложения мы создаем папку конфигурации и помещаем в нее параметры региона. Поэтому любые файлы, живущие под корнем 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> . . .поэтому, если мы развертываем в регионе выпуска, инструмент сборки просто будет иметь действие для замены файлов в корне конфигурации файлами из соответствующая папка региона. Структура файла выглядит примерно так:
добавлено: вот как выглядит структура управления версиями, развернутое приложение будет иметь только конфигурационный каталог без вложенных папок или курса
\Root web.config \Config appsettings.config services.config logging.config \release appsettings.config services.config logging.config \debug appsettings.config services.config logging.configон довольно чистый и поддерживается любым автоматизированным инструментом сборки(копирование/замена файлов). Хороший побочный эффект заключается в том, что разработчики могут создавать различные вкусы и держать их под контролем исходного кода, не затрагивая "реальные" конфигурации.
вы хотите, чтобы задача XmlMassUpdate в MSBuildCommunityTasks (делает то, что вы пытаетесь сделать с вашим консольным приложением xml)
http://msbuildtasks.tigris.org/
используйте его так
<XmlMassUpdate Condition=" '@(ConfigTemplateFile)'!='' And '@(ConfigSubstitutionsFile)'!=''" ContentFile="@(ConfigTemplateFile)" SubstitutionsFile="@(ConfigSubstitutionsFile)" MergedFile="@(ConfigFile)" ContentRoot="/configuration" SubstitutionsRoot="/configuration/substitutions/$(Configuration)"/>
вы можете использовать события сборки для управления веб-конфигурациями. Хансельман есть хорошая статья об этом.
в основном у вас есть все ваши различные веб.конфигурации в решении вы затем создаете (некоторые) новые типы сборки. В зависимости от типа сборки вы запускаете веб.конфигурация копируется поверх указанной!
Я использую способ Скотт Хансельман (Он объясняет это гораздо лучше, чем я могу воспроизвести это так, перейдите по ссылке :) ) Он отлично работал для меня...
Я использую это средство: xmlpreprocess
мы поддерживаем отдельные файлы свойств для каждой среды, которые объединяются в сценарии развертывания.
Мне нравится использовать задачу сборки для автоматизация изменение конфигурационного файла для нужной среды.
мы используем теги в наших конфигурационных файлах, которые заменяются во время сборки, чтобы отразить предполагаемую среду развертывания. Я был вдохновлен блог Lavablast
приятно иметь только один файл конфигурации шаблона для управления.
недостатком является то, что вы не можете иметь пользовательские "профили".
старый вопрос, но так как он имеет высокий ранг в поиске Google, я подумал, что это хорошая идея, чтобы добавить web.синтаксис преобразования конфигурации, что был доступен с VS2010. С помощью этого инструмента, вы можете иметь различные веб.конфигурационные файлы для различных сборок (Debug / Release)
вот краткое резюме о том, как иметь две строки подключения - один для разработки (режим отладки) и один для производства (режим выхода):
1 - Установите строка подключения разработки в интернете.конфигурационный файл. Должно выглядеть примерно так:
<connectionStrings> <add name="myConnectionString" connectionString="Data Source=TestDBServer; (etc...)" /> </connectionStrings>2-разверните свой веб.config и откройте web.освобождать.конфигурации
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-предварительный просмотр преобразования в интернете.конфигурационный файл, который будет использоваться во время сборки выпуска, щелкнув правой кнопкой мыши в интернете.освобождать.конфигурационный файл и выбор Предварительный Просмотр Преобразования.
Я традиционно использовал несколько веб.конфигурации, как вы упомянули. Это может быть боль, но она смягчается с помощью инструментов сравнения файлов, таких как BeyoneComapare2 или KDIff...
раздражение:
Я упомянул мое маленькое приложение cmd line для слияния XML-документов в моем 1-м обновлении... Ну для этого я просто использую XmlDocument, и в конечном итоге просто .Сохраните () его в файловый поток.
к сожалению, узлы на самом деле не находятся в каком-либо определенном порядке, и, по-видимому, .NET требует элемент
является первым дочерним элементом документа. Я думал, что все эти причудливые инструменты должны были сделать жизнь программированию легче?
мои любимые два способа борьбы с этим:
A. сохраните параметры на целевом компьютере* - в Azure, например, вы можете настроить параметры приложения и строки подключения, которые будут переопределять значения в web.конфиг. (*- или определение целевой машины, если конфигурация инфраструктуры является динамической).
B. сделайте инструмент сборки / развертывания (TeamCity, Octopus Deploy и т. д., VS Team Services) внедрить конкретные значения среды как часть сборки и/или развертывание. Современные инструменты поддерживают шифрование конфиденциальных настроек.