Программа замены файлов XML? (web.config / WDP related)

Question

Я столкнулся с множеством ограничений, связанных с кодом замены web.config в проекте VS Deployment Project 2008 года. Некоторые из них кажутся:

• Группы разделов не могут быть заменены, только разделы. Если бы я только знал, что такое разделы.
• Кажется, есть некоторые требования к замене. Это не просто «тупая» текстовая замена. Это затрудняет замену пользовательских дополнений к web.config (кажется, файлы, поддерживающие разделы, должны быть в GAC или что-то подобное).

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

• Работает с файлами XML
• Учитывая INI-файл, такой как список ключей / значений
• Может заменить элементы в исходном XML-файле текстовым содержимым, загруженным из текстовых файлов, указанных значениями в файле INI.

Или я тут что-то не так делаю? Код замены конфигурации WDP кажется довольно бесполезным (и трудно найти документацию).

Answer 1

По моему опыту, мне было проще иметь три файла в моем проекте, скажем, Web-Release.config, Web-Debug.config и Web.config, а затем я изменяю файл проекта (который является просто MSBuild). скрипт), чтобы скопировать содержимое файла -Debug или -Release поверх Web.config в процессе сборки. К счастью, этот тип поведения, очевидно, встроен в Visual Studio 2010, но в настоящее время его довольно легко добавить, просто щелкнув правой кнопкой мыши файл проекта, выгрузив его, а затем отредактировав файл для переключения:

<Target Name="AfterBuild">
    <Copy SourceFiles="Web-Debug.config" DestinationFiles="Web.config" ContinueOnError="false" Condition="'$(Configuration)' == 'Debug'" />
    <Copy SourceFiles="Web-Release.config" DestinationFiles="Web.config" ContinueOnError="false" Condition="'$(Configuration)' == 'Release'" />
&lt/Target>

Другой вариант, который я использовал в прошлом, заключался в создании задачи MSBuild для этого слияния XML-файлов . Это было полезно для генерации App.config файлов, которые были предоставлены для общего доступа на сервере с хостом консольного приложения Windows (для отладки) и хостом службы Windows (для производства): большинство общих настроек находились в App.config в общем ресурсе проекта, и у каждого хост-проекта был App.config, который определял дополнительные настройки, и затем я редактировал проект MSBuild каждого хост-проекта, чтобы запустить свое пользовательское задание, чтобы объединить два App.config в один большой App.config. Но это было, вероятно, излишним.

Я думаю, что проще создать файл .config для каждого из ваших сценариев развертывания, как описано выше. Если есть много общего, использование атрибута configSource для элементов может сократить дублирование.

Надеюсь, это поможет решить природу вашей проблемы, хотя, вероятно, это было не совсем то, что вы искали.

Answer 2

отказ от ответственности: я собираюсь спамить вас, рассказывая о моей программе, которую я написал для этого

Я написал что-то для этого: dashy . Это немного связано с настройкой (возможно, зависит от вашей среды), но оно предназначено для решения именно вашей проблемы - управления вашими настройками для различных сред (и, кроме того, их развертывания).

В качестве альтернативы, предварительно, я просто использовал nant-задачи с конкретными .properties для каждой среды и выполняю соответствующую, после сборки.