Для веб-приложений
MSBuild знает, как преобразовать файлы web.config на основе следующих настроек / свойств / параметров (по порядку)
- Конфигурация сборки
dotnet publish --configuration Release
- Опубликовать профиль
dotnet publish --configuration Release /p:PublishProfile=FolderProfile
- Окружающая среда
dotnet publish --configuration Release /p:EnvironmentName=Production
- Пользовательское преобразование файла
dotnet publish --configuration Release /p:CustomTransformFileName=custom.transform
Я думаю, что для разработчиков характерно, чтобы это происходило на основе только конфигурации сборки, и я считаю, что MSBuild (и dotnet) знают, как это сделать, основываясь на элементе <DependentUpon>Web.config</DependentUpon>
вWeb. [Configuration] .config элемент в файле проекта или сценария сборки.
Devure Azure Выпуск конвейеров немного отличается.Конвейер хочет преобразовать ваш web.config после того, как проект был собран / опубликован, и не знает, как это сделать, если MSBuild (или dotnet) уже попытался это сделать.Таким образом:
[предупреждение] Невозможно применить преобразование для данного пакета.Проверьте следующее.[Предупреждение] 1.Применяется ли уже преобразование для сгенерированного пакета MSBuild во время сборки.Если да, удалите тег для каждой конфигурации в файле csproj и пересоберите.[Предупреждение] 2.Убедитесь, что файл конфигурации и файлы преобразования находятся в одной папке внутри пакета.
В тексте предупреждения указано:
- Удалите тег
<DependentUpon>
для каждой конфигурациив csproj - Таким образом: вам нужно удалить тег из csproj, чтобы предотвратить преобразование MSBuild файлов
- Или: вам нужно использовать аргумент
/p:TransformWebConfigEnabled=False
для MSBuild. (примечание: я считаю правильным, что это можно использовать без удаления зависимого тега, но я могу ошибаться)
- Убедитесь, что преобразованиеисходный и целевой файлы находятся в одной папке внутри пакета.
- Может быть несколько способов сделать это.Я решил пометить исходные файлы конфигурации преобразования как содержимое, чтобы MSBuild включил их в опубликованный пакет.
Теперь вам нужно организовать конвейер выпуска в соответствии сдокументация Преобразования файлов и подстановки значений .
[раздел] Запуск: IIS Web App Deploy====================================Задача: развертывание IIS Web AppОписание. Развертывание веб-сайта или веб-приложения с использованием веб-развертывания.Версия: 0.0.51Автор: Microsoft CorporationСправка: Дополнительная информация ==================================== ...[команда] C: ... \ ctt \ ctt.exe s: C: ... \ Web.config t: C: ... \ Web.Release.config d: C: ... \ Web.config pwя[команда] C: ... \ ctt \ ctt.exe s: C: ... \ Web.config t: C: ... \ Web.Development.config d: C: ... \ Web.config pwяПреобразования XML успешно применены...
Для не-веб-приложений, нуждающихся в преобразовании .config
Передача файлов .config в конвейер выпуска может происходить несколькими способами.Вот два.
Ваш выпуск должен иметь «доступ» к хранилищу как часть артефакта, что обеспечит загрузку исходного кода агентом развертывания (не желательно IMHO).
Вам потребуется включить файлы web. [Stage] .config в состав артефакта сборки с задачей копирования или мини-сопоставлением, которое их забирает.
Как только у вас есть файлы .config, доступные для конвейера выпуска
Вы можете использовать задачу XDT Transform для выполнения операций преобразования.
Вариант 2 - маршрут, который я прошел.
Вот изображение того, как эта задача выглядит для меня.
Эта задача помещает конфигурацию в артефакт из сборки, которую я затем могу использовать в конвейере выпуска, не перестраивая xx раз.