Проблема развертывания с помощью веб-развертывания и списков контроля доступа

Я развертываю веб-приложение на своем хосте с помощью веб-развертывания. При запуске из Visual Studio с помощью команды «Опубликовать» все работает нормально. Когда я пытаюсь выполнить развертывание с помощью веб-развертывания из MSBuild, веб-сайт становится недоступным, и даже веб-панель управления моего веб-хоста больше не может получить доступ к веб-сайту. Я отследил это до того, что, по моему мнению, является разрешениями для папок веб-сайта.

Публикация из Visual Studio обновляет списки контроля доступа, и веб-сайт работает правильно, а панель управления веб-хоста работает (даже если она была нарушена при развертывании из MSBuild).

Ниже приводится результат при запуске из Visual Studio:

------ Publish started: Project: mywebapp, Configuration: Release Any CPU ------
Transformed Web.config using Web.Release.config into obj\Release\TransformWebConfig\transformed\Web.config.
Auto ConnectionString Transformed Views\Web.config into obj\Release\CSAutoParameterize\transformed\Views\Web.config.
Auto ConnectionString Transformed obj\Release\TransformWebConfig\transformed\Web.config into obj\Release\CSAutoParameterize\transformed\Web.config.
Copying all files to temporary location below for package/publish:
obj\Release\Package\PackageTmp.
Start Web Deploy Publish the Application/package to https://myhost.net:8172/MsDeploy.axd?site=mywebapp.com ...
Updating setAcl (mywebapp.com).
Updating setAcl (mywebapp.com).
Updating filePath (mywebapp.com\bin\mywebapp.Core.dll).
Updating filePath (mywebapp.com\bin\mywebapp.Core.pdb).
Updating filePath (mywebapp.com\bin\mywebapp.dll).
Updating filePath (mywebapp.com\bin\mywebapp.pdb).
Updating filePath (mywebapp.com\Views\Web.config).
Updating filePath (mywebapp.com\web.config).
Updating setAcl (mywebapp.com).
Updating setAcl (mywebapp.com).
Publish is successfully deployed.
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========
========== Publish: 1 succeeded, 0 failed, 0 skipped ==========

Я обнаружил файл, который, как мне кажется, использует Visual Studio во время развертывания, который содержит информацию ACL. Он называется myapp.SourceManifest.xml и находился в папке C: \ Projects \ mywebapp \ obj \ Release \ Package .

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <contentPath path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" />
  <setAcl path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" setAclResourceType="Directory" />
  <setAcl path="C:\Projects\mywebapp\obj\Release\Package\PackageTmp" setAclUser="anonymousAuthenticationUser" setAclResourceType="Directory" />
</sitemanifest>

Мой файл MSBuild содержит следующее для выполнения развертывания :

<Exec Command='"$(ProgramFiles)\IIS\Microsoft Web Deploy v2\msdeploy.exe" -verb:sync -source:package="mywebapp\obj\test\package\mywebapp.zip" -dest:auto,computername="https://myhost.net:8172/MsDeploy.axd?site=mywebapp.com",username=XXXX,password=XXXX,authtype=basic -allowuntrusted:true -setparam:name="IIS Web Application Name",value="mywebapp.com"' />

Когда я запускаю MSBuild для развертывания, я вижу, что файлы обновляются, но списки управления доступом не обновляются.

Мое развертывание MSBuild происходит из другой папки из-за другой конфигурации (тестовая, а не релизная) и другой файл mywebapp.SourceManifest.xml .

<?xml version="1.0" encoding="utf-8"?>
<sitemanifest>
  <IisApp path="C:\Projects\mywebapp\obj\Test\Package\PackageTmp" managedRuntimeVersion="v4.0" />
</sitemanifest>

Другой mywebapp. Файлы SourceManifest.xml , вероятно, имеют к этому какое-то отношение? Что мне нужно сделать, чтобы обновить списки ACL?

Обновление

Я обнаружил, что разница в файле mywebapp.SourceManifest.xml была вызвана наличием следующего в файле. csproj для моей тестовой конфигурации.

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>

Я изменил его на True , и теперь файлы манифеста одинаковы между тестовой и выпускной конфигурациями.

Я также обнаружил, что при использовании публикации из Visual Studio , что он работает для Release, но не работает для Test. Итак, сейчас я пытаюсь выяснить, чем отличаются две конфигурации, которые приводят к успешному или неудачному развертыванию.