Я пытаюсь обновить процесс развертывания для сайта .NET Framework до веб-приложения Azure. Ранее мы использовали командлет Publish-AzureWebsiteProject PowerShell, но он постепенно прекращается. Поэтому мы пытаемся использовать функциональность kudu zipdeploy с помощью недавно выпущенного командлета Publish-AzWebApp PowerShell. Все прекрасно работает, когда файлы доставляются в Azure, но ужасно не удается распаковать ZIP-файл в нужное место.
Когда я создаю сайт, используя цель "Package" на нашем сервере сборки, он создает ZIP-файл, структурированный для использования с MSDeploy. Это не тот формат, который ожидается методом zipdeploy. ZIP-файл MSDeploy включает в себя XML-файл развертывания, а фактическое содержимое глубоко вложено в путь, представляющий исходное местоположение. Похоже, Zipdeploy хочет простой архив корня содержимого веб-сайта, поэтому он копирует файлы из архива в буквальный путь после извлечения.
Так, например, если мое решение Visual Studio находится в d:\builds\solution, тогда файлы сборки для упаковки помещаются в d:\builds\solution\project\obj\debug\Package\PackageTemp. Содержимое сайта попадает в ZIP по следующему пути D_C\builds\solution\project\obj\debug\Package\PackageTemp\Content. В результате при запуске zipdeploy содержимое помещается в веб-приложение по адресу wwwroot/Content/D_C/builds/solution/project/obj/debug/Package/PackageTemp/Content/.
Команда, которую я запускаю для создания проекта:
msbuild.exe /nologo /v:minimal /T:Package /p:Configuration="Debug;VisualStudioVersion=12.0" project.csproj
Я надеюсь, что кто-то знает, как мне этого добиться одним из следующих способов (преференциальный порядок):
- аргумент msbuild для создания сайта и создания простого содержимого ZIP
- параметр kudu, который будет развертывать текущий ZIP с использованием msdeploy вместо прямой копии
- пользовательский сценарий развертывания kudu, который будет развертываться через msdeploy вместо копии файла
- настройка цели msbuild, которая создаст совместимый ZIP