Что происходит с веб-развертыванием из службы Visual Studio и App?

Внезапно веб-развертывание запустилось.

Could not find file 'D:\home\site\wwwroot\App_Offline.htm'.

Я остановил службу, но развертывание все еще не работает.

Когда я пытался удалить любой файл из wwwroot в пользовательском интерфейсе Kudu PowerShell, я получаю ошибку "404 файл не найти", но этот файл все еще отображается после обновления. Когда я попытался удалить файл непосредственно в powershell, я получаю ошибку

Cannot remove item D:\home\site\wwwroot\Azure.Storage.dll: Invalid access to memory location.
At line:1 char:1
+ del .\Azure.Storage.dll
+ ~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (D:\home\site\wwwroot\Azure.Storage. 
   dll:FileInfo) [Remove-Item], IOException
    + FullyQualifiedErrorId : RemoveFileSystemItemIOError,Microsoft.PowerShell 
   .Commands.RemoveItemCommand

Я удалил службу, ее воссоздал, и первое развертывание из Visual Studio было в порядке. Но на следующий день развертывание снова не удалось. Единственное, что было между этими развертываниями, - это развертывание с VSTS. Но мне не удалось решить проблему с VSTS и Visual Studio в любом порядке.

Я являюсь владельцем этого приложения.

Журнал развертывания.

(2018-08-06 13:05:03) An error occurred when the request was processed on the remote computer.
Could not find file 'D:\home\site\wwwroot\App_Offline.htm'.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean useAsync)
   at System.Xml.XmlWriterSettings.CreateWriter(String outputFileName)
   at System.Xml.XmlWriter.Create(String outputFileName, XmlWriterSettings settings)
   at Microsoft.Web.Deployment.AppOfflineRuleHandler.AddAppOfflineFilesToEachApp(DeploymentBaseContext baseContext, Boolean whatIf)
   at Microsoft.Web.Deployment.AppOfflineRuleHandler.AddChild(DeploymentSyncContext syncContext, DeploymentObject destinationParentObject, DeploymentObject& sourceObject, Boolean& proceed)
   at Microsoft.Web.Deployment.DeploymentSyncContext.HandleAddChild(DeploymentObject destParent, DeploymentObject sourceObject, Int32 position)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncDirPathChildren(DeploymentObject destRoot, DeploymentObject sourceRoot)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildren(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildrenNoOrder(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildren(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildrenNoOrder(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildren(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildrenOrder(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.SyncChildren(DeploymentObject dest, DeploymentObject source)
   at Microsoft.Web.Deployment.DeploymentSyncContext.ProcessSync(DeploymentObject destinationObject, DeploymentObject sourceObject)
   at Microsoft.Web.Deployment.DeploymentObject.SyncToInternal(DeploymentObject destObject, DeploymentSyncOptions syncOptions, PayloadTable payloadTable, ContentRootTable contentRootTable, Nullable'1 syncPassId, String syncSessionId)
   at Microsoft.Web.Deployment.DeploymentAgent.HandleSync(DeploymentAgentAsyncData asyncData, Nullable'1 passId, String user, String siteName)
Publish failed to deploy.

Ответ 1

Внезапно режим развертывания VSTS по умолчанию стал Run-From-Zip.

Решением является установка флажка Выбрать метод развертывания в развертывании VSTS и убедитесь, что выбран Веб-развертывание.

Чтобы "разблокировать" сервис, вам необходимо удалить настройки WEBSITE_RUN_FROM_ZIP со страницы настроек приложения

Примечание. Новое имя этих настроек: WEBSITE_RUN_FROM_PACKAGE

Ответ 2

У меня была та же проблема сегодня с сетевым ядром 2.2, и решение было удалить настройку "WEBSITE_RUN_FROM_PACKAGE" в настройках приложений Azure.

Ответ 3

Мы столкнулись с этой же проблемой - файловая система становится WEBSITE_RUN_FROM_PACKAGE=1 только для WEBSITE_RUN_FROM_PACKAGE=1 когда WEBSITE_RUN_FROM_PACKAGE=1. Служба приложений Azure, похоже, автоматически добавляет этот параметр приложения во время последних обновлений платформы.

Я предлагаю использовать Run-From-Package через веб-развертывание, но вы можете легко отменить их принудительное обновление, установив WEBSITE_RUN_FROM_PACKAGE=0. Если вы работаете в Azure DevOps - последняя версия App Service Deploy v4 поддерживает Run-From-Package.

Ответ 4

Удалите настройки appp WEBSITE_RUN_FROM_ZIP, а затем повторите попытку развертывания из VS. Это сработало для меня

Ответ 5

Если вы выбрали метод развертывания самостоятельно на этапе выпуска, это не должно появиться:

Ответ 6

В моем развертывании произошел сбой с тем же сообщением и трассировкой стека, но оно было вызвано назначением политики, запрещающим расположение моего ресурса.

(Ресурс был создан на западе США, а затем была применена политика на уровне корня арендатора, которая позволяла только Запад США 2).

После обновления политики развертывание прошло успешно.