Управление сложными файлами 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 ]

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

Раздражение:

Я упомянул мое маленькое приложение cmd line для объединения XML-документов в моем первом обновлении ... Для этого я просто использую XmlDocument и, в конце концов, просто .Save () его в FileStream.

К сожалению, узлы на самом деле не в каком-то определенном порядке, и, очевидно, .NET требует, чтобы элемент был первым дочерним элементом документа.

Я думал, что все эти причудливые инструменты должны были облегчить жизнь программированию ?

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