Использование преобразований SlowCheetah Config в файле Web.config в приложении Web Forms версии 3.5

Я загрузил SlowCheetah в старое приложение веб-форм .Net 3.5, чтобы добавить преобразования в web.config.

В прошлом я успешно использовал SlowCheetah со службами Windows и консольными приложениями для преобразования app.config. В этих случаях конфигурация преобразуется и помещается в корзину как ApplicationName.exe.config.

Однако с этим приложением веб-форм файл конфигурации никогда не оказывается в корзине, поскольку сайты веб-форм создаются только с добавлением .dll в корзину, а IIS указывает на корневой каталог для запуска сайта. Таким образом, вместо включения файла web.config в процесс сборки и его упаковки в корзину, он просто остается в корневом каталоге.

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

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

Кто-нибудь знает, как заставить преобразования работать с моим web.config или включить его в процесс сборки, чтобы slowCheetah мог творить чудеса?

Спасибо!

Обновить

Я изменил свойства файла web.config, и теперь он включен в сборку, однако преобразования к нему по-прежнему не применяются.

Действие сборки: встроенный ресурс

Копировать в выходной директор: Всегда копировать


webforms msbuild asp.net-3.5 slowcheetah
person Michael    schedule 25.04.2013    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Решение

Я переименовал Web.config в нашей системе контроля версий в Web.template.config и добавил преобразования Web.template.Debug.config и Web.template.Release.config.

Затем выгрузите файл проекта и отредактируйте XML-файл .csproj, добавив следующие элементы.

Это создает новый файл Web.config в корневом каталоге. Вау!

<PropertyGroup>
  <PrepareForRunDependsOn>
    $(PrepareForRunDependsOn);
    WebConfigTransform;
  </PrepareForRunDependsOn>
</PropertyGroup>
<Target Name="WebConfigTransform">
  <Message Text="Configuration: $(Configuration): Web.template.$(Configuration).config" />
  <TransformXml Source="Web.template.config" 
                Transform="Web.template.$(Configuration).config" 
                Destination="Web.config" />
</Target>
person Michael    schedule 26.04.2013

arrow_upward
1
arrow_downward

Нашел лучшее решение — без переименования файлов в .template.config.

Вставьте следующее в свой файл Web Forms .csproj.

  <Target Name="BeforeBuild">
    <Delete Files="$(TEMP)\Web.TEMP.config" />
    <Copy SourceFiles="Web.config" DestinationFiles="$(TEMP)\Web.TEMP.config" />
    <TransformXml 
      Source="$(TEMP)\Web.TEMP.config"
      Transform="Web.$(Configuration).config"
      Destination="Web.config" />
  </Target>
person Vasyl Boroviak    schedule 25.06.2013
comment
Проблема здесь в том, что вы создаете своего рода циклическую ссылку. Скажем, у вас есть преобразование, которое вставляет элементы. При первом запуске он возьмет содержимое web.config и вставит новые элементы, а при втором запуске преобразования вы вставите повторяющиеся элементы. Кроме того, имейте в виду, если вы используете web.config в системе управления версиями, хотите ли вы, чтобы он постоянно менялся? - person Michael; 25.06.2013
comment
Согласен на циркулярный выпуск. Хотя мы используем только преобразование SetAttribute, так что оно отлично работает для нас. - person Vasyl Boroviak; 27.06.2013
comment
Для нас важно иметь Web.config под контролем исходного кода. Таким образом решение. Но я согласен, что ваше решение предпочтительнее. - person Vasyl Boroviak; 27.06.2013