Aspnetcore: Развертывание завершается сбоем из-за используемого файла

Я заметил аналогичную проблему с блокировкой файлов IIS на виртуальных машинах Azure, которая препятствовала развертыванию WebDeploy. Мой обходной путь — выполнить три команды WebDeploy: остановить AppPool, развернуть, перезапустить AppPool. Смотрите мой сценарий ; и если у вас есть возможность запускать три команды WebDeploy, вы можете сделать что-то подобное с Azure Apps.

Получение этой проблемы в beta6.

То же самое! Это приводит к тому, что моя Visual Studio 2015 фактически зависает - при публикации моего приложения vNext (я думаю, как beta6, так и beta7).

Используете ли вы сценарии, предоставленные Microsoft , для выполнения развертывания? Если это так, вы можете просто добавить строку в PublishAspNet5Website.ps1 , чтобы перезапустить веб-приложение:

Restart-AzureWebsite -Name $websiteName

У меня есть изменения в сценарии сборки, описанные в этом сообщении: Устранение проблемы с развертыванием ASP.NET 5 в слоте веб-приложения Azure .

@brandonmartinez , перезапуск веб-сайта не поможет, так как рабочий веб-сайт будет продолжать получать запросы, что приведет к повторной блокировке файлов. В настоящее время единственный надежный способ обновить веб-сайты IIS и Azure — закрыть пул приложений веб-сайта, затем обновить файлы и перезапустить веб-сайт. Просто перейдите по ссылке @GuardRex для более подробной информации.

Однако нам не нужно возиться с пользовательскими сценариями развертывания при работе в условиях по умолчанию с VS2015.

Надеюсь, новая инфраструктура HttpPlatformHandler (которая больше не нуждается в AspNet.Loader.dll) будет немного более снисходительной, но здесь я не задерживаю дыхание. Вероятно, мы получим еще одну заблокированную .dll.

@rubenprins Это обходной путь, который я также использую с помощью инструментов Azure SDK в VS.

Для этого есть команды PS, если вы можете получить доступ PS к виртуальной машине. https://github.com/GuardRex/net5-iis-ps-publish/blob/7623122dbfdc55a7c53c8edd2e97443e0eea22c9/net5-iis-ps-publish.ps1#L389 -L396

aspnet/vsweb-publish тоже очень интересен; однако похоже, что он использует offline-template.html , и я думал, что было обнаружено, что этот метод не предотвратит проблему блокировки dll ... только остановка AppPool, развертывание и перезапуск AppPool были стабильными, рабочий подход.

нам не нужно возиться с пользовательскими сценариями развертывания при работе в условиях по умолчанию с VS2015.

Однако мне пришла в голову одна вещь: возможность использовать «публикацию в файловой системе» и подключение сценария сразу после публикации, в котором есть биты MSDeploy, позволила очень простую и полезную историю развертывания для нескольких виртуальных машин. Поскольку сценарий выполняется последовательно, он просто переходит от ВМ к ВМ по цепочке. Делает приятный кофе-брейк. :улыбка:

У меня есть вопрос в разделе Приступая к настройке балансировщика нагрузки с выходом в Интернет с помощью Azure Resource Manager , а команда Azure Resource Manager спрашивает, как указать балансировщику нагрузки временно прекратить отправку трафика на виртуальную машину во время развертывания.

В любом случае... возвращаясь к теме, которую поднял @pekkah . Поскольку мы знаем, что команды PS работают, проверьте параметры для их выполнения в сборке VSO:

Microsoft/vso-агент-задачи
Запустите скрипт в процессе сборки
Запуск сценариев предварительной сборки в Team Foundation Service (Visual Studio Online) для процесса сборки Azure Continuous Deployment
Новые функции автоматизации сборки в Visual Studio Online

... да ... что-то вроде этого должно сработать для вас.

Здесь та же проблема...

Все еще жду официального решения

Бруно

Это будет решено https://github.com/aspnet/IISIntegration/issues/81.

@moozzyk , эта проблема исправит развертывание только с помощью специальных инструментов, таких как msdeploy. Развертывание Xcopy/File sync по-прежнему будет невозможно, что также будет блокировать/препятствовать многим сценариям CI, которые просто работают с ASP.NET v1-4.

Проблема все еще существует в ASP.NET Core 1.0 RC2 с Visual Studio 2015.2 MSDeploy для IIS 8 в Windows 2012 R2 с новейшими инструментами для сервера. Уничтожение процесса dotnet.exe или перезапуск пула приложений решает проблему. Но для этого требуется доступ к серверу через удаленный рабочий стол, и это не совсем гладкий процесс.

@ dg9ngf - теперь это ошибка в web.deploy. Они добавили функциональность app_offline.htm для Azure, но по умолчанию она отключена при локальном развертывании. Попробуйте открыть свой профиль публикации (PublishProfiles->*.pubxml) и изменить:

<EnableMSDeployAppOffline>False</EnableMSDeployAppOffline>

к

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

Если это не сработает, спросите @vijayrkn

Если вы используете инструменты VS для публикации с помощью профиля msdeploy, это свойство автоматически добавляется в ваш файл pubxml.

<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>

В окне вывода вы должны увидеть команду msdeploy, подобную этой.

"C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\vramak\AppData\Local\Temp\PublishTemp\obj\SourceManifest.xml' -dest:manifest='C:\Users\vramak\AppData\Local\Temp\PublishTemp\obj\DestManifest.xml',ComputerName='https://netcoreappwithdb.scm.azurewebsites.net/msdeploy.axd',UserName='$netcoreappwithdb',Password='{PASSWORD-REMOVED-FROM-LOG}',IncludeAcls='False',AuthType='Basic' -verb:sync -enablerule:AppOffline -enableRule:DoNotDeleteRule -retryAttempts:20

-e nablerule:AppOffline в команде должен позаботиться о добавлении appOffline во время развертывания.

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

<AppOfflineTemplate>Path to app offline</AppOfflineTemplate>

Это свойство _не_ присутствовало в файле .pubxml, созданном Visual Studio. Поэтому я добавил его, но это ничего не изменило. Аргумент -e nablerule:AppOffline _не_ появляется в окне вывода.

Можете ли вы поделиться командной строкой msdeploy, отображаемой в окне вывода?

Кроме того, можете ли вы подтвердить, что pubxml имеет WebPublishMethod как «MSDeploy».
<WebPublishMethod>MSDeploy</WebPublishMethod>

Нет, в файле вместо этого: <WebPublishMethod>FileSystem</WebPublishMethod>

Вот командная строка из окна вывода: Executing command ["C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" -source:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\SourceManifest.xml' -dest:manifest='C:\Users\yves\AppData\Local\Temp\PublishTemp\obj\DestManifest.xml' -verb:sync -enableRule:DoNotDeleteRule -retryAttempts:20 -disablerule:BackupRule]

Я выполняю развертывание с помощью задачи «Развертывание веб-приложения Azure» в VSTS, как описано в этом сообщении в блоге: http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2 .

Есть ли способ указать <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> с помощью этого метода?

Привет, у меня была такая же проблема в Azure, я решил таким образом https://github.com/davidebbo/WAWSDeploy/issues/14.

@ dg9ngf В текущей версии скрипта powershell мы поддерживаем appOffline только для WebPublishMethod — «MSDeploy».

Поддержка AppOffline для публикации файловой системы будет доступна в следующем выпуске.

@bojingo я в такой же ситуации. Вы поняли это?

@davenewza : Если вы снова посетите этот пост в блоге, решение находится в комментариях.
http://donovanbrown.com/post/2016/05/30/DevOps-for-ASPNET-Core-RC2

В основном вам нужно добавить шаги VSTS, чтобы остановить/запустить сайт. Очень далекое от идеального решение (на самом деле, довольно хромое), тем более, что я не использую слоты развертывания, но оно нормально работает для нашей среды разработки/тестирования.

Существует новая предварительная ARM-версия задачи VSTS по развертыванию веб-приложений, которая основана на msdeploy и обещает исправить ее, но мне не повезло с ней, потому что мне нужно, чтобы клиент создал субъект-службу для подписки, и что было хлопотно. Может быть, вы можете заставить это работать:
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn Диалоговое окно «Публикация в Интернете» в VS2015 не содержит никаких параметров для установки msdeploy — только дает параметры для WebPublishMethod = FileSystem.

Можете ли вы предоставить образец .pubxml для WebPublishMethod=msdeploy, пожалуйста?

@tomfanning Для основного консольного приложения ASP.NET единственным доступным в настоящее время вариантом публикации является файловая система. Вы пытаетесь опубликовать консольное приложение? Для веб-приложения должны быть доступны все эти 4 параметра (веб-развертывание, пакет веб-развертывания, файловая система и ftp).
Пример веб-развертывания pubxml — https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Если это веб-приложение, и вы видите только опцию публикации файловой системы, можете ли вы проверить xproj, чтобы узнать, импортирует ли он это?
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingo Мне удалось настроить субъект-службу, в сети есть несколько руководств. У меня нет ссылок здесь, но я могу найти их, если вам нужно. Теперь моя проблема в том, что для задачи требуется файл parameters.xml, который не создается при публикации ASP Net Core... :(

У меня есть локальная версия TFS 2015, и это остается невероятно раздражающей проблемой.

Я тоже сталкиваюсь с этой проблемой...

Мое решение состояло в том, чтобы остановить развертываемый промежуточный слот, а затем опубликовать его (автоматическая замена работает). Перезапуск, затем развертывание не сработало (развертывание с помощью VSTS)

Я использую Octopus с веб-приложениями Azure, которые не предоставляют возможности для промежуточных слотов. Однако проверка следующих параметров, похоже, сработала:

• Безопасно отключите домен приложения с помощью пустого файла app_offline.html в корневом каталоге.
• Удалите файлы в месте назначения, которые не являются частью развертывания.

Я использую Visual Studio 2015 Update 3 для публикации сайта asp.net core 1.1/.net framework 4.5.2 в IIS. Он падает на App_Offline.htm , что не останавливает сайт. Если я переименую его на сервере в app_offline.htm , сайт перестанет работать.

Для этого app_offline.htm не должен учитывать регистр.

https://github.com/aspnet/IISIntegration/issues/81

Разработчик загружает app_offline.htm (без учета регистра)

Я только что снова опубликовал и вижу, что App_Offline.htm упал, и мой сайт не отключился, и я получаю сообщение об ошибке «Файл используется». Когда я изменяю его на app_offline.htm , мой сайт отключается, и я могу публиковать его без ошибок.

Я размещаюсь на общем пути UNC - я не знаю, имеет ли это значение.

@Tratcher - знаете ли вы, почему здесь имеет значение регистр App_Offline.htm?

jayvijayrkn см. https://github.com/aspnet/AspNetCoreModule/issues/50

Мне удалось решить эту проблему, добавив параметр приложения Azure

MSDEPLOY_RENAME_LOCKED_FILES = 1

... как описано здесь:
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-260946957

YMMV

@BenBarreth Есть ли что-то подобное, применимое не к Azure?

не то, чтобы я знал про извините @jdshkolnik

Кажется, что могут быть проблемы с MSDEPLOY_RENAME_LOCKED_FILES = 1. Это помогает успешному развертыванию, но может означать, что новые библиотеки DLL не загружаются во время выполнения:
https://github.com/Azure/azure-webjobs-sdk-script/issues/569#issuecomment-264490818

Мне это не кажется подходящим "исправлением". Он просто скрывает сбой развертывания.

Истинное исправление может быть описано в этом выпуске:
https://github.com/Azure/azure-webjobs-sdk-script/issues/1023

Действительно ищет решение для этого. Похоже, задача веб-развертывания RM VSTS позаботилась об этом с выбранной опцией «Перевести приложение в автономный режим», но с этих выходных мы постоянно получаем ошибки. Мы вернулись к остановке слота развертывания, развертыванию и запуску снова.

Как и у нас, эта проблема возникла в пятницу на прошлой неделе и с тех пор не позволяет нам развертывать...

То же самое. Похоже, это влияет только на сайты с Always On = true, но это не точно.

У меня все еще есть эта проблема, даже когда я устанавливаю MSDEPLOY_RENAME_LOCKED_FILES = 1 в моей конфигурации. Сейчас практически невозможно обновить сборку на моем сервере. Это начало происходить буквально несколько дней назад.

Та же проблема начала возникать для меня на этой неделе. Вплоть до этой недели развертывание службы приложений AzureRM в VSTS с параметром Take App Offline = true постоянно работало. Теперь этот параметр либо игнорируется, либо служба вовремя не отключается. Мне приходится вручную перезапускать или останавливать/запускать службу приложений во время выполнения релиза для нее слишком много.

Та же проблема здесь. AzureRm работал несколько месяцев и внезапно остановился. Мое последнее развертывание было две недели назад, 5 декабря, и теперь, 20 декабря, он генерирует файл Error_File_In_Use. Очень раздражает необходимость вернуться к ручному запуску/остановке.

Вот наш обходной путь в Powershell, который мы сейчас используем как часть нашего процесса CI/сборки. Особая благодарность ребятам из @appveyor за помощь в этом:

$username = $env:deployusername
$password = $env:deploypassword
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Headers = @{
  'Authorization' = ('Basic {0}' -f $base64AuthInfo)
  'If-Match'      = '*'
}
$apiUrl = "https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm"
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

Это позволяет использовать Kudu REST API для HTTP PUT app_offline.htm файла app_offline.htm с правильным регистром на месте. У нас есть WebDeploy, настроенный на удаление любых файлов, не входящих в развертывание, поэтому он автоматически удаляет файл как часть развертывания. Возможно, вам придется повторить этот шаг, используя HTTP DELETE , чтобы удалить файл после завершения развертывания, если вы не используете этот режим.

Добавление Trackyon Stop перед задачей AzureRM и задачей Trackyon Start после нее работает хорошо для меня. В этом нет необходимости с TakeAppOffline = true, но это работает и позволяет избежать ручного управления или сценариев. Просто добавьте задачу в определение выпуска. Ступени Trackyon легко настроить.

21 декабря 2016 г., в 00:10, Чад Т. < notifications @github.comnotifications@ github.com > написал:

Вот наш обходной путь в Powershell, который мы сейчас используем как часть нашего процесса CI/сборки. Отдельное спасибо ребятам @appveyor https://github.com/appveyor за помощь в этом:

$username = $ env:deployusername
$ пароль = $ env: деплойпароль
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $username,$password)))
$Заголовки = @{
'Авторизация' = ('Базовая {0}' -f $base64AuthInfo)
'Если-совпадение' = '*'
}
$apiUrl = " https://YourAzureWebsite.scm.azurewebsites.net/api/vfs/site/wwwroot/app_offline.htm "
$filePath = "app_offline_tmp.htm"
Invoke-RestMethod -Uri $apiUrl -Headers $Headers -Method PUT -InFile $filePath -ContentType "multipart/form-data"

Это использует Kudu REST API https://github.com/projectkudu/kudu/wiki/REST-API для HTTP PUT правильно оформленного файла app_offline.htm. У нас есть WebDeploy, настроенный на удаление любых файлов, не входящих в развертывание, поэтому он автоматически удаляет файл как часть развертывания. Возможно, вам придется повторить этот шаг, используя HTTP DELETE, чтобы удалить файл после завершения развертывания, если вы не используете этот режим.

-
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959 или отключите звук в ветке https://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTcgaJpZM4FJp_R .

Это сообщение не является общедоступным и может содержать привилегированную, проприетарную или конфиденциальную информацию. Если вы получили его по ошибке, немедленно сообщите об этом отправителю и удалите все копии оригинала. Любое другое использование вами электронной почты запрещено. Любое несанкционированное копирование, хранение, использование или раскрытие содержимого этого сообщения не допускается и может быть незаконным. Если это разрешено местным законодательством, электронные сообщения с Lithero могут отслеживаться и сканироваться нашими системами в целях информационной безопасности и оценки внутреннего соответствия политикам Lithero и применимым законам.

/ копия @davidebbo

Попробуйте установить MSDEPLOY_RENAME_LOCKED_FILES=1 в настройках приложения Azure для своего приложения.

@davidebbo , похоже, это ничего не решает.

Я предполагаю, что это связано с изменением на стороне забора Azure? Многие люди (особенно на слабом канале aspnet) столкнулись с этой проблемой одновременно.

Изменение в Azure не объясняет, почему мы наблюдаем это локально с TFS. Может это агент?

Мы наблюдаем ту же проблему. App_Offline.htm не подхватывается. Как ни странно, если мы развертываем из VS, он работает хорошо.

Как ни странно, у меня не работает из VS, как описано здесь: #1883

Моя команда также сталкивается с этой проблемой, почти каждый раз, когда происходит сбой развертывания из-за заблокированного файла. Необходимо перезапустить каждое приложение в Azure и повторно запустить развертывание. Мы используем Octopus Deploy.

Моя команда столкнулась с этой проблемой сегодня утром. Есть комментарии от команды Microsoft? Конвейер выпусков имеет решающее значение для нашей производительности, он предотвращает выпуски на производственные площадки. Спасибо!

@bmoscao — app_offline.html чувствителен к регистру.

Эта проблема также появилась у меня на Azure. Я ничего не сделал с моей стороны, чтобы вызвать это.

У меня тоже есть эта проблема. Дело в том, что для EnableMSDeployAppOffline установлено значение true , а выходные данные проекта показывают -enablerule:AppOffline как часть команды, выполняемой визуальной студией. Я не уверен, что делать... Я только недавно начал получать эту проблему..

Наш обходной путь для этого состоял в том, чтобы остановить пул приложений, развернуть, а затем перезапустить пул приложений. Для этого мы используем Release Manager и встроенный плагин powershell .

Останавливаться:

param( [string]$webApp, [string]$subscriptionName, [string]$resourcegroupName );  
Select-AzureRmSubscription -SubscriptionName $subscriptionName; 
Stop-AzureRmWebapp -Name $webApp -ResourceGroupName $resourcegroupName

Начинать:

param( [string]$webApp, [string]$subscriptionName, [string]$resourcegroupName );  
Select-AzureRmSubscription -SubscriptionName $subscriptionName; 
Start-AzureRmWebapp -Name $webApp -ResourceGroupName $resourcegroupName

Определенно был бы признателен за некоторый вклад от Microsoft, хотя раньше это отлично работало, просто включив правило appOffline на этапе развертывания RM Azure.

@davidebbo Мы используем ASP.NET Core, VSTS Release Manager и AzureRmWebApp со слотами.

@davidebbo спасибо! Меня устраивает ;)

У нас тоже происходит — msdeploy в Azure. Рад видеть, что это таинственным образом началось для многих людей одновременно - и это не только для нас - но в целом это не очень обнадеживает!

Я не думаю, что людям в MS нужно подтверждение для этого, вероятно, они хорошо знают, в чем проблема. Во всяком случае, здесь так же. Развёртывание из VSTS, перестало работать в начале декабря. На данный момент я использую задачу trackyon для остановки/запуска.

Просматривая эту тему, для каждой записи не всегда ясно:

1. касается ли проблема службы приложений Azure или какого-либо другого хостинга.
2. пытались ли люди изменить регистр app_offline, как обсуждалось выше. Кажется, несколько человек сообщили об успехе там.
3. пробовали ли MSDEPLOY_RENAME_LOCKED_FILES . Опять же, несколько человек, кажется, преуспели в этом.

Если вы столкнулись с этой проблемой, пожалуйста, четко укажите, каков ваш сценарий и что вы пробовали, чтобы мы могли понять это. Спасибо!

@davidebbo

Я получаю сообщение ERROR_FILE_IN_USE при попытке выполнить развертывание с помощью Visual Studio/MSBuild. Задача заключается в создании файла App_Offline.htm на сервере, но не в отключении приложения.

Создание файла app_offline.htm с помощью Web Deploy приводит к отключению приложения.

Это моя установка:

• Сервер: IIS 8, .NET Core Windows Server Hosting 1.1.0 и веб-развертывание 3.6.
• Моя машина: Visual Studio 2015 Update 3 и инструменты .NET Core 1.0.1 Preview 2
• Опубликовать профиль:

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <_SavePWD>False</_SavePWD>
    <ADUsesOwinOrOpenIdConnect>False</ADUsesOwinOrOpenIdConnect>
    <AllowUntrustedCertificate>True</AllowUntrustedCertificate>
    <DeployIisAppPath>...</DeployIisAppPath>
    <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline>
    <EnableMSDeployBackup>True</EnableMSDeployBackup>
    <EnvironmentName>Production</EnvironmentName>
    <ExcludeApp_Data>False</ExcludeApp_Data>
    <LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
    <LastUsedPlatform>Any CPU</LastUsedPlatform>
    <LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
    <MSDeployPublishMethod>WMSVC</MSDeployPublishMethod>
    <MSDeployServiceURL>...</MSDeployServiceURL>
    <PublishFramework>netcoreapp1.1</PublishFramework>
    <PublishRuntime>win81-x64</PublishRuntime>
    <RemoteSitePhysicalPath />
    <SiteUrlToLaunchAfterPublish />
    <SkipExtraFilesOnServer>False</SkipExtraFilesOnServer>
    <UsePowerShell>True</UsePowerShell>
    <UserName>...</UserName>
    <WebPublishMethod>MSDeploy</WebPublishMethod>
  </PropertyGroup>
</Project>

@davidebbo

Я прокомментировал эту ошибку в аналогичной теме, и мне приходилось останавливать и перезапускать мое веб-приложение Azure каждый раз, когда я хочу повторно развернуть (только в среде разработки). Никогда не приходилось делать это до этой недели. Я решил в основном создать основное веб-приложение Visual Studio 2015 .net из шаблона без каких-либо изменений.

Я запустил веб-приложение на локальном хосте без проблем.
Я без проблем публикую новое приложение в своем плане службы веб-приложений Azure, и браузер сразу же открывает сайт без проблем.
Я проверил панель управления Azure и никаких проблем.

Затем я пошел и переиздал веб-приложение, ничего не изменив — код или настройки, и возникла следующая ошибка.

С этого момента мне приходится останавливать веб-приложение, публиковать его в Azure, а затем запускать веб-приложение. Это никогда не случалось со мной раньше. Это очень простое развертывание шаблона Microsoft.

Я записал весь этот процесс и отправил отзыв в систему обратной связи Microsoft 2015 VS. Надеюсь, вы сможете найти эту запись. Или я, вероятно, мог бы сделать это снова.

С уважением Питер

@davidebbo

касается ли проблема службы приложений Azure или какого-либо другого хостинга.

Служба приложений Azure.

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

Изменение App_Offline на app_offline устраняет проблему — этот файл создается через веб-развертывание автоматически с корпусом «App_Offline» как часть развертывания, что является сутью проблемы.

@davidebbo
Точно так же, как @ctolkien.

@davidebbo

касается ли проблема службы приложений Azure или какого-либо другого хостинга.

В моем случае я выполняю развертывание в службе приложений Azure. Не знаю насчет других хостингов.

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

Я использую задачу «Развертывание веб-приложения AzureRM» из VSTS (https://aka.ms/azurermwebdeployreadme). Есть опция «Опубликовать с помощью веб-развертывания» <- отмечена и «Отключить приложение в автономном режиме» <- отмечена, которая работала, пока что-то где-то не изменилось и она перестала работать.
Всплывающая подсказка «информация» явно сообщает о размещении «app_offline.htm» со строчной буквой «a».
Я не уверен, как изменить его с помощью этого скрипта, он уже должен быть в нижнем регистре.

пробовали ли MSDEPLOY_RENAME_LOCKED_FILES. Опять же, несколько человек, кажется, преуспели в этом.

Не пробовал. Не знаю, как это сделать. Но в любом случае я бы предпочел отключить приложение, а не изменять содержимое заблокированных файлов.

Спасибо всем. Таким образом, кажется очевидным, что основная проблема связана с регистром app_offline.htm , а не с чем-либо, связанным со службой приложений Azure (откуда я родом). И это отслеживается https://github.com/aspnet/AspNetCoreModule/issues/50.

Я предлагаю закрыть эту тему и оставить другую. Я позволю экспертам ASP.NET сделать это оттуда, если только нет оснований полагать, что Azure Web App частично виноват (маловероятно, основываясь на том, что @fabiano сообщает о том же за пределами Azure).

На самом деле это выглядит как регресс в инструментарии, где, кажется, начали создавать App_Offline.html вместо app_offline.html. @mlorbetske , @vijayrkn - есть идеи, что это может быть?

Понятно, значит, вы говорите, что основная среда выполнения (AspNetCoreModule) всегда была чувствительна к регистру, но раньше это не было проблемой, потому что VS использовала соответствующий регистр, а теперь нет?

Несмотря на это, я бы сказал, что среда выполнения не должна быть чувствительна к регистру, поэтому есть два возможных пути решения проблемы.

@davidebbo - это правильно. Я считаю, что AspNetCoreModule всегда был чувствителен к регистру.

@davidebbo

а не что-либо, связанное со службой приложений Azure (откуда я родом)

Я предполагаю, что причина привлечения Azure AppService к обсуждению заключается в том, что без каких-либо изменений от нашего имени все просто начало давать сбой, мы не изменили ни одну из наших версий пакета. Была ли редакция ANCM изменена в службах приложений?

@ctolkien да, я думаю, что он действительно был обновлен. Так что вполне может быть, что приведенный выше вывод неверен. Вместо этого новая теория такова:

• Более старый ANCM (7.1.1965.0) не был чувствителен к регистру.
• Более новый (7.1.1970.0) стал чувствительным к регистру.
• На стороне публикации VS ничего не изменилось, и регистр всегда был App_Offline.htm .

@moozzyk как вы думаете, это возможно, или вы уверены, что это всегда было чувствительно к регистру?

@moozzyk @davidebbo - Инструменты VS для корпуса app_offline не изменились. Инструментарий VS вызывает msdeploy с правилом appoffline (-enablerule:AppOffline), а msdeploy удаляет App_Offline.htm.

Эта проблема выглядит как изменение поведения в ANCM. Судя по первому комментарию здесь, app_offline должен быть нечувствительным к регистру (https://github.com/aspnet/IISIntegration/issues/81).

@ctolkien

Изменение App_Offline на app_offline устраняет проблему.

Где мне изменить это? Я делаю MSDEPLOY прямо из Visual Studio в Azure.

@oyvindvol

Где мне изменить это? Я делаю MSDEPLOY прямо из Visual Studio в Azure.

Насколько я знаю, вы не можете изменить регистр App_Offline из MSDEPLOY, вам нужно будет создать собственный сценарий для решения на данный момент. Вы можете использовать сценарий powershell, который я разместил выше, в качестве отправной точки.

Чтобы сообщить всем, мы подтвердили, что приведенная выше теория верна: ошибка чувствительности к регистру является регрессией в более новой версии ANCM, и эта версия была развернута в службе приложений Azure в декабре, что привело к тому, что пользователи внезапно столкнулись с этим.

План состоит в том, чтобы получить исправление ANCM от группы ASP.NET Core и развернуть его в службе приложений. ETA пока нет, но это должно произойти где-то в январе.

Спасибо!

@davidebbo Сможем ли мы загрузить ANCM для установки на наш собственный сервер с помощью iis и устранить эту конкретную ошибку?

@Pictuel Я бы так подумал. Обратите внимание, что моя точка зрения здесь строго касается службы приложений Azure, поэтому я позволю основной группе комментировать сценарии, не относящиеся к Azure.

спасибо за наводку :)

@Pictuel да, мы позаботимся о том, чтобы была выпущена обновленная версия установщика хостинга Windows для .NET Core, содержащая обновление для ANCM.

@ширхатти

@shirhatti Я слежу здесь, когда обновленный установщик доступен для обновления ссылок на документы.

Пройдя через этот поток, я не совсем уверен, что такое обходной путь именно для Служб приложений. Это настройка приложения или используется настраиваемый сценарий развертывания или остановка и запуск сайта?

Если это настройка приложения, я читал другой комментарий, в котором говорилось, что веб-сайт не получает новые библиотеки DLL.

Если я правильно понял, с нашей стороны нет обходного пути, пока на ANCM не будет доступно обновление (https://github.com/aspnet/AspNetCoreModule/issues/50). Службы приложений должны обновляться командой Azure.

Я думаю, что лучше всего в Службе приложений остановить/запустить приложение, как описано здесь @dtmnash .

@davidebbo «План состоит в том, чтобы получить исправление ANCM от команды ASP.NET Core и развернуть его в службе приложений. Пока нет ожидаемого времени прибытия, но это должно произойти где-то в январе». -- Дайте нам знать, когда ETA будет готово по этому вопросу :)

Ориентировочное время развертывания — между 24 и 30 числами. Развертывание происходит постепенно для множества единиц масштабирования, поэтому не все получат исправление в одно и то же время.

Спасибо, у меня это только начало работать :-)

Все еще проблема для меня :(

@hbunjes спасибо за подтверждение!

@rsnj это происходит постепенно в течение некоторого периода времени. Все это должно быть сделано к концу месяца (если мы не столкнемся с проблемой).

Развертывание @davidebbo работает для некоторых моих приложений, но не для всех. Странно то, что некоторые развертывания завершаются с ошибкой, а другие — нет для приложений, работающих в одном и том же плане службы приложений. Можно ли увидеть, какая версия ANCM работает для конкретного веб-приложения?

@henningst См. https://github.com/aspnet/AspNetCoreModule/issues/50#issuecomment -271381892, чтобы проверить.

Вчера у меня не работало, а сейчас ЕСТЬ. Спасибо @davidebbo!

Это начало работать и для меня. Спасибо!

Да, развертывание завершено, поэтому оно должно работать для всех.

У меня и здесь все хорошо.

Кажется, сейчас работает. Судя по отчету, на исправление этого ушло больше года. Я бы предпочел, чтобы вопросы развертывания имели более высокий приоритет: p

Как исправить это для не-Azure?

@pekkah Я думаю, что у него были определенные проблемы. Последний был намного старше одного года.

@jdshkolnik для не-Azure, я думаю, вам просто нужно начать использовать новый ANCM.

@jdshkolnik
Обновление доступно для загрузки по адресу https://www.microsoft.com/net/download/core#/runtime .
Это прямая ссылка на скачивание.

@shirhatti Я установил это, но все еще получаю эти ошибки.

Я все еще получаю сообщение об ошибке в Сан-Паулу, Южная Бразилия.

@jdshkolnik Какую версию вы видите, когда запускаете это в PowerShell?

[System.Diagnostics.FileVersionInfo]::GetVersionInfo("C:\Windows\System32\inetsrv\aspnetcore.dll").FileVersion

@ширхатти 7.1.1971.0

Обновление : извините, это была моя вина. Я просматривал и обновлял этапы развертывания существующего выпуска, а не определение выпуска. Я уже сбился со счета, сколько раз я это делал...

Я все еще сталкиваюсь с этой ошибкой каждый раз, когда пытаюсь выполнить развертывание, хотя моя версия aspnetcore.dll предположительно исправлена.

Версия aspnetcore.dll : 7.1.1971.0
Развернуто с помощью : задача VSTS Развертывание службы приложений Azure v3.* (предварительная версия)
Перевод приложения в автономный режим : отмечено
Удалить дополнительные файлы в месте назначения : отмечено
Переименовывать заблокированные файлы : проверено
Настройка приложения MSDEPLOY_RENAME_LOCKED_FILES : не добавлено

На данном этапе мне не ясно, какие настройки нужны или не нужны для того, чтобы это работало.

Только что снова возникла проблема с моим первым файлом в службах приложений Azure:

2017-02-14T22:41:10.4400186ZC:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe — источник: IisApp= 'D:/a/r1/a/Ascend Ammo Portal/drop/apps /artifacts/AmmoPortal' — Dest:IisApp= 'core-asyoz77ajoed4/ammo-preview',ComputerName=' https://core-asyoz77ajoed4.scm.azurewebsites.net/msdeploy.axd?site=core-asyoz77ajoed4/ammo-preview ',UserName='$core-asyoz77ajoed4',Password=' * * ',IncludeAcls='False',AuthType='Basic' - verb:sync -retryAttempts=20 -verbose -e nablerule:AppOffline

2017-02-14T22:41:34.3837386Z Код ошибки: ERROR_FILE_IN_USE

2017-02-14T22:41:34.3837386Z Дополнительные сведения: веб-развертывание не может изменить файл Ascend.Ammo.Portal.exe в месте назначения, так как он заблокирован внешним процессом. Чтобы операция публикации прошла успешно, вам может потребоваться либо перезапустить приложение, чтобы снять блокировку, либо использовать обработчик правил AppOffline для приложений .Net при следующей попытке публикации. Дополнительные сведения см. по адресу: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.

2017-02-14T22:41:34.3837386Z Количество ошибок: 1.

К вашему сведению: документы, похоже, ссылаются на установщик старой версии (*.1970): https://docs.microsoft.com/en-us/aspnet/core/publishing/iis#install -the-net-core- Пакет хостинг-серверов Windows.

Кроме того, похоже, что на странице загрузки среды выполнения есть исправление только для версии LTS?

@shirhatti ~ Сообщите мне, когда будет готова новая ссылка на программу установки пакета хостинга, и я включу ее в документацию (она есть в нескольких местах). ~

~ Это: https://go.microsoft.com/fwlink/?linkid=837808 ... это не ссылка aka.ms, хотя. ~

Я устанавливаю https://github.com/aspnet/Docs/pull/2773 , чтобы покрыть это, если fwlink в порядке.

Также происходит в визуальной студии, и, как показывают параметры, присутствует правило автономного режима приложения.

@davidebbo , не могли бы вы подтвердить, что это исправлено? Слышал от довольно многих людей, что они все еще бьют его. Было ли это исправлено в выпускной версии инструментария или это все еще проблема с хостингом?

Я также пытаюсь выяснить, почему и когда это происходит. Я почти уверен, что видел, что процесс запущен в обозревателе процессов на сайте scm, и он опубликован просто отлично.

Я также обновляю свои сайты до новейших инструментов, надеясь, что проблема связана со старыми инструментами project.json.

Исправление было развернуто в службе приложений Azure некоторое время назад, и я не знаю, чтобы кто-то все еще сталкивался с проблемой после этого. Конечно, пользователи на узлах, отличных от Azure, могут по-прежнему видеть его, если они не были обновлены.

Если у вас возникла проблема с Azure, проверьте ее следующим образом:

• Перейдите в обозреватель процессов Kudu и убедитесь, что процесс вашего приложения запущен (обычно это dotnet.exe).
• Вручную создайте файл app_offline.htm (например, запустите touch app_offline.htm ) из команды Kudu.
• Снова проверьте обозреватель процессов и убедитесь, что этого процесса больше нет.

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

Но я проверю, как вы просили.

Кроме того, мы используем масштабирование + приложения, развернутые в виртуальных приложениях — не знаю, изменит ли это что-нибудь.

@pksorensen , выполняющий это «вручную», поможет изолировать все, что может делать WebDeploy. т.е. если простое удаление app_offline.htm не останавливает процесс, то мы действительно знаем, что проблема не вызвана WebDeploy.

Обратите внимание, что обычно вы получаете процесс dotnet.exe, а в вашем случае у вас другое имя exe. Интересно, это как-то связано с проблемой?

1. Перейдите в обозреватель процессов Kudu и убедитесь, что процесс вашего приложения запущен (обычно это dotnet.exe).
   Я сделал это, но это не dotnet.exe, а наше имя, скомпилированное bin Ascend.Ammo.RegistrationTablet.exe

Затем я коснулся app_offline.htm, но это не убило процесс.

Я делаю что-то не так, потому что не вижу dotnet.exe?

Я позволю экспертам dotnet/ANCM прокомментировать эту часть. Я знаю, что по умолчанию при развертывании основного приложения ASP.NET используется dotnet.exe. Я думаю, что случай, когда это не так, - это когда вы используете автономный развертывание (или как оно там называется). Но я понятия не имею, как это влияет на ANCM и app_offline.htm.

@DamianEdwards , кто может лучше всего прокомментировать это?

Я избегаю этой проблемы, используя слоты развертывания. Работает 100% времени. Остановите слот перед копированием файлов. Это удалит все из памяти, поэтому ваша копия не будет работать без заблокированных файлов. Затем запустите слот и переключитесь на производство. Дополнительная выгода: ваши клиенты никогда не увидят автономную страницу приложения. Они получают развертывание с нулевым временем простоя.

http://donovanbrown.com/post/MicrosoftCodeAnalysisCSharpdll-Locked-Problem-Fix

Слот @DarqueWarrior , конечно, работает (и его можно использовать по другим причинам), но ключевой момент в этой ветке — понять, почему app_offline оказывается неэффективным при завершении процесса Core для некоторых людей, таких как @pksorensen. И я хотел бы, чтобы команда Core прокомментировала это.

@davidebbo Чтобы ответить на ваш предыдущий вопрос, переносимость и автономность не имеют отношения к поведению app_offline. Автономный файл приложения отслеживается w3wp.exe (модулем ASP.NET Core).

@DarqueWarrior Спасибо за совет, хотя один комментарий — если вы, как и мы, развертываете несколько сайтов в виртуальных приложениях в одной и той же службе приложений, слоты (если я правильно помню) работают во всех них, поэтому вам придется развернуть все сайты до обмен. Это хлопотно. Прямо сейчас мы можем легко развертывать части (микросервисы) в отдельных виртуальных приложениях. Конечно, мы можем распределить их по отдельным службам приложений, но тогда нам потребуются балансировщики нагрузки/шлюзы, чтобы заставить их снова использовать один и тот же домен, что также требует больше времени, чем мы готовы сделать прямо сейчас.

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

@pksorensen, есть шанс, что вы сможете создать репродукцию на фиктивном сайте и поделиться ее именем? По сути, я хотел бы видеть его в том состоянии, в котором работает ваш сайт, и ручное создание app_offline.htm в консоли Kudu не приводит к его закрытию.

@shirhatti есть идеи, что может привести к тому, что ANCM не остановит процесс? Насколько агрессивно он пытается это сделать?

@davidebbo Это займет у меня немного времени, но я постараюсь что-нибудь придумать, чтобы создать репродукцию.

@davidebbo Я создал новое приложение ASP.NET Core и новую службу приложений Azure. Я использую функцию Azure «Непрерывная доставка (предварительная версия)», и у меня возникает эта проблема.

2017-03-30T02:54:36.5648892Z ##[ошибка]Не удалось развернуть службу приложений.
2017-03-30T02:54:36.5658893Z ##[ошибка]Код ошибки: ERROR_FILE_IN_USE
2017-03-30T02:54:37.1850861Z Дополнительные сведения: веб-развертывание не может изменить файл myApp.dll в месте назначения, так как он заблокирован внешним процессом. Чтобы операция публикации прошла успешно, вам может потребоваться либо перезапустить приложение, чтобы снять блокировку, либо использовать обработчик правил AppOffline для приложений .Net при следующей попытке публикации. Дополнительные сведения см. по адресу: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.
2017-03-30T02:54:37.1860517Z Количество ошибок: 1.
2017-03-30T02:54:37.4179909Z ##[ошибка]Ошибка: C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe не удалось с кодом возврата: 4294967295

Создание вручную app_offline.htm в папке D:\home\site\wwwroot действительно останавливает процесс dotnet.exe.

Значит ли это, что есть проблема с самой «непрерывной доставкой (предварительная версия)»?

В дополнение к вышесказанному я исправил это, вручную перейдя в «Определение выпуска VSTS», «Дополнительные параметры развертывания», отметив «Отключить приложение».

Но это вызывает несколько вопросов:
Почему по умолчанию не установлен флажок «Перевести приложение в автономный режим»? Должен ли этот сценарий по-прежнему работать (например, сокращает ли он время простоя)?

Если да, то почему не получается? Если нет, то почему «Непрерывная доставка (предварительная версия)» не отмечена?

В любом случае - похоже, что где-то есть ошибка.

@ Jon12345 Jon12345 : эта ветка посвящена только обсуждению того, правильно ли работает app_offline.htm с основными приложениями. Таким образом, тот факт, что VSTS может или не может делать это по умолчанию, на самом деле является отдельным обсуждением, которое следует вести на форуме VSTS (вероятно, https://social.msdn.microsoft.com/Forums/vstudio/en-US/ дом?форум=TFService).

На данный момент кажется, что большинство людей были разблокированы после исправления. Был один отчет о том, что @pksorensen не работает, и мы ждем репро-приложения, чтобы посмотреть на него.

Я все еще получаю это в TFS 2017 Update 1.

@jdshkolnik Вы уверены, что он настроен на создание файла appoffline.htm? Если нет, то это выходит за рамки данного вопроса. Выполните ручной тест appoffline.htm, как описано выше.

@davidebbo Да, это так. Часто случается так, что запланированное ночное развертывание завершается с ошибкой с первой попытки и требует попытки повторного развертывания вручную, которая обычно завершается успешно.

К вашему сведению, моя фирма объединена с вашей, поэтому я могу легко показать вам ее с помощью общего доступа к рабочему столу Skype для бизнеса.

@jdshkolnik , пожалуйста, убедитесь, что вы выполнили ручной тест, описанный выше, так как это помогает исключить все остальное из уравнения.

Важно ! Эта проблема не связана с расследованием каких-либо проблем с VSTS или другими рабочими процессами публикации. Речь идет только об одном: убедиться, что appoffline.htm работает.

@davidebbo Он отключается, как только я вручную помещаю app_offline.htm в папку.

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

##[section]Starting: Deploy IIS App: \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip
==============================================================================
Task         : WinRM - IIS Web App Deployment
Description  : Connect via WinRM, to deploy Web project locally on IIS, using Web Deploy
Version      : 1.4.3
Author       : Microsoft Corporation
Help         : [More Information](http://aka.ms/IISWebDeploy)
==============================================================================

Preparing task execution handler.

Executing the powershell script: I:\Agent\_work\_tasks\IISWebAppDeploy_50acc50f-7d15-470b-83c1-578b3f3eeba2\1.4.3\Main.ps1
name='db-Web.config Connection String',value='Data Source=dbserver;Database=Internal_QA;Type System Version=SQL Server 2012;User ID=xxx;Password=yyy;Persist Security Info=True')

Starting deployment of IIS Web Deploy Package : \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip

Performing deployment in sequentially on all machines.

Deployment started for machine: usserver with port 5985.

Deployment status for machine usserver : Failed

##[error]Microsoft.PowerShell.Commands.WriteErrorException: System.Exception: Error Code: ERROR_FILE_IN_USE

For more info please refer to http://aka.ms/iisextnreadme

##[error]PowerShell script completed with 1 errors.

##[section]Finishing: Deploy IIS App: \\usserver\Deploy\CD_146_QA\Installer\Install\Web\App.Web.zip

@jdshkolnik Я думаю, что все, что делает этот сценарий развертывания, не создает appoffline.htm перед публикацией файлов. Это может быть проблема с конфигурацией VSTS или ошибка. Но с точки зрения ANCM, проведенный вами тест показывает, что при создании приложения appoffline все работает должным образом.

@davidebbo Я не уверен, что то, что я сделал, было окончательным тестом. Ведь вторая ручная попытка после того, как мы получим ошибку, обычно оказывается успешной. Процесс развертывания, который мог заблокировать app_offline.htm, не был запущен.

Я все еще сталкиваюсь с этой проблемой, чувствительной к регистру, на 7.1.1971.0. Когда я пытаюсь развернуть с помощью VS, я получаю сообщение об ошибке блокировки файла, поэтому я посмотрел, работает ли приложение, и, конечно же, это так. Я открыл командную строку Kudu, чтобы посмотреть, какие файлы находятся в каталоге wwwroot и App_Offline.htm в папке, но процесс все еще выполнялся. Затем я набрал touch app_offline.htm, и процесс перестал работать, как и ожидалось. Я дважды проверил модули, и моя версия aspnetcore.dll — 7.1.1971.0.

@alexgritton это странно. Казалось бы, это означает, что ANCM изначально не обнаружил файл. Это происходит последовательно или случайно?

Я только что создал приложение сегодня в Службах приложений Azure, и это происходило весь день, поэтому я бы сказал, последовательно. Есть ли у вас другие идеи о том, что может быть причиной этого?

Не совсем. Я позволю экспертам ANCM прокомментировать, как они отслеживают изменения файлов, и могут ли они придумать причину, по которой первоначальное создание не обнаруживается.

@davidebbo У меня точно такая же проблема. У моей команды есть поддельная сборка, которая копирует файл AppBuild.htm с сервера сборки на целевой сайт как app_offline.htm. Затем мы пытаемся использовать msdeploy для синхронизации папки и получения ошибки открытия другим процессом. Если я коснусь файла, переименую файл из app_offline.htm в app_offline.htm.rename и обратно или перезапишу app_offline.htm с помощью проводника, тогда процесс остановится должным образом. Не совсем понятно, почему это не работает через наш скрипт, но работает, если мы делаем это вручную.

Обновление: мы обнаружили, что обновление времени последней записи постоянно вызывает отключение:

Target "StopApi" (fun _ ->                                    
    trace "Deployment - Stopping Api"                 

    for folder in apiWebDeployShare do                        
        let offlineFile = folder @@ "app_offline.htm"         
        let offlineFileSource = folder @@ "AppOffline.htm"    
        CopyFile offlineFile offlineFileSource                
        File.SetLastWriteTime (offlineFile, DateTime.Now)     
)                

Определенно что-то не так с кодом, который отслеживает файл app_offline.htm.

@derekgreer Итак, вы видите, что когда вы копируете файл, отключение не срабатывает? Я не могу воспроизвести это с консоли Kudu. например

• Перейти в консоль Куду
• Запустите touch app_offline.htm в D:\home\site , чтобы создать пустой файл в другой папке.
• Запустите copy app_offline.htm wwwroot . Обратите внимание, что при этом сохраняется время последней записи и обновляется время создания (стандартное поведение при копировании файлов).

Результат: процесс dotnet.exe мгновенно останавливается (можно проверить с помощью обозревателя процессов Kudu).

Эти же шаги работают для вас? Если да, то что может отличаться в вашем сценарии воспроизведения?

На самом деле, я должен был также добавить, что эта проблема возникала периодически и что мы используем IIS 8 на Windows Server 2012.

Сегодня утром я намеревался посмотреть, смогу ли я воспроизвести проблему с помощью powershell или пакетного сценария перед настройкой консоли Kudu, но предварительно протестировав тестовый сценарий сборки Fake, который моя команда использовала в пятницу для создания файла app_offline.htm в различными способами (копировать существующий файл, создать новый файл и т. д.), в настоящее время он работает. Это также отражает характер наших сбоев при сборке, когда процесс иногда останавливался, а иногда нет. Когда он действительно начинает давать сбои, он, кажется, делает это постоянно. Мы тестировали в течение нескольких часов в пятницу, и он неизменно не останавливался на простой сборке Fake, которая абсолютно ничего не делала, кроме создания нового файла app_offline.htm. Я также должен добавить, что мы периодически создаем файл вручную и видим, как процесс останавливается, поэтому не может быть такой ситуации, когда процесс не выключится после некоторого продолжительного периода использования.

Когда я смогу воспроизвести проблему снова, я посмотрю, отражает ли проблема создание файла с помощью powershell и/или пакетного файла.

@davidebbo Ну, дерьмо ... Я только что заметил, что забыл закомментировать строку, которая обновляла время последнего обновления, поэтому она действительно все еще показывает то же поведение. Сейчас я попробую с powershell и командным файлом и сообщу вам.

@davidebbo

Извините за путаницу. Хорошо, вот что я нашел:

Использование пакетного файла со следующим содержимым, по-видимому, надежно приводит к завершению процесса:

echo "" > \\testserver\e$\Site.Api\app_offline.htm

Использование эквивалентного сценария bash также надежно приводит к завершению процесса:

#!/bin/bash

echo "" > //testserver/e$/Site.Api/app_offline.htm

Использование сценария powershell со следующим содержимым, по-видимому, никогда не приводит к завершению процесса:

New-Item \\testserver\e$\Site.Api\app_offline.htm -type file

Учитывая, что и Fake, и Powershell работают в среде CLR, а команда копирования DOS, bash и консоль Kudu — нет, похоже, это указывает на что-то, связанное с файлом, созданным с помощью среды CLR.

Странно то, что я не вижу различий в отметках времени создания/обновления результирующего файла между различными версиями.

@derekgreer О, значит, вы вообще не используете Службу приложений Azure. Это моя точка зрения во всей этой саге, поэтому я позволю людям ASP.NET прокомментировать это дальше.

Хотя для чего мне не удалось воспроизвести в App Service:

• Используйте консоль PowerShell Kudu
• Перейдите в папку site\wwwroot
• Выполнить New-Item app_offline.htm -type file

@moozzyk , вы можете помочь расследовать репродукцию @derekgreer за пределами службы приложений?

Дополнительная информация:

Поскольку создание, копирование, переименование и т. д. с помощью проводника всегда работало, я решил посмотреть, отражает ли приложение для проводника на основе .Net те же результаты, что и с Fake и PowerShell. Есть проводник на основе .Net под названием «Nomad», который я скачал и протестировал, и результаты совпали с Fake и PowerShell. При создании файла app_offline.htm процесс не останавливался. Затем я переименовал файл и снова переименовал его в app_offline.htm, после чего процесс Core закрылся.

https://github.com/aspnet/AspNetCoreModule/blob/93ace1b84bd79382233cb39b858611d2db05552e/src/AspNetCore/Src/filewatcher.cxx#L321

Я думаю, что этот метод захочет включить флаг «FILE_NOTIFY_CHANGE_CREATION».

Интересно, не активирует ли .Net API, общий для Fake, PowerShell и Nomad, эти другие флаги так же, как обычное создание файла.

@shirhatti , не могли бы вы убедиться, что кто-то расследует эту потенциальную проблему с ANCM?

@davidebbo Ак. мы изучаем это

У меня очень похожая проблема. Если я скопирую файл app_offline.htm в проводнике Windows, то он правильно остановит процесс, но если я создам его с помощью COPY app_offline.htm \server\share\siteapp_offline.htm с моего сервера сборки, то он не остановится, и файлы останутся заблокированными .

@gulbanana У меня точно такая же проблема, как и у тебя. Вы уже решили это? @shirhatti Есть новости о вашем расследовании? Это сводит команду с ума, потому что конвейер CI постоянно дает сбой из-за сбоев копирования файлов, которые, в свою очередь, вызваны тем, что dotnet.exe не закрывается app_offline.htm.

Я работал над проблемой, используя что-то вроде echo "<html>page content</html>" > \\server\share\app_offline.htm . Я думаю, что @derekgreer прав в том, что ошибка связана с тем, что ANCM отслеживает только некоторые методы создания файлов, и он ловит этот.

@derekgreer
Я изучаю проблему сейчас. С помощью одной из ваших команд воспроизведения на моей тестовой машине я смог воспроизвести эту проблему. Я использовал команду ниже. (ПРИМЕЧАНИЕ: приведенная ниже команда создаст пустой файл (нулевой размер файла).

new-item \\iisdist\privates\jhkim\temp\PublishOutput\app_offline.htm -ItemType file

Одна интересная вещь: если я добавлю содержимое файла при создании файла app_offline.htm, проблем не будет. Это можно сделать, просто добавив параметр -value «test» следующим образом:

new-item \\iisdist\privates\jhkim\temp\PublishOutput\app_offline.htm -ItemType file -value "test"

Можете ли вы подтвердить, видите ли вы тот же симптом в вашей среде воспроизведения?
Если это так, я думаю, что эта проблема возникает только тогда, когда пустой app_offline.htm создается каким-то особым образом, например с помощью команды powershell new-item.

@gulbanana
Я не могу воспроизвести эту проблему с помощью команды «Копировать». Можете ли вы объяснить более подробно суть вашего репродукции? Было бы здорово, если бы вы смогли найти несколько шагов воспроизведения, с помощью которых я могу воспроизвести ту же проблему на моей тестовой машине.

Я могу подтвердить, что это не связано с тем, является ли файл app_offline.htm пустым без запуска этих команд, поскольку наш опыт заключался в копировании файла с желаемым содержимым в папку развертывания. Основываясь на своем опыте, я предполагаю, что вторая команда может вызывать событие изменения файла, если она действительно работает. Возможно, он создает файл и впоследствии обновляет его содержимое. Несмотря на это, каждый связанный с .net процесс, который я использовал для создания файла с содержимым или без него, не может вызвать завершение процесса.

@shirhatti Любое обновление? Удалось ли вам подтвердить, что ваш код должен использовать флаг «FILE_NOTIFY_CHANGE_CREATION»?

@derekgreer Мы прослушиваем все допустимые флаги, кроме изменения последнего доступа и изменения атрибутов.
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

Так что да, мы уже слушаем FILE_NOTIFY_CHANGE_CREATION .

копия: @pan-wang

@shirhatti А, теперь я понимаю. Я не знал, что этот флаг покрывает создание изменений. Мне интересно, вы смогли воспроизвести проблему?

Предположительно исправлено отсутствие реакции на пустой app_offline.htm: https://github.com/aspnet/IISIntegration/issues/174 .

@moozzyk @derekgreer Спасибо за подтверждение. Хорошо, я также обнаружил, что проблема не связана напрямую с содержимым пустого файла. Я сообщу вам после выяснения основной причины.

@jhkimnew У меня больше нет точной сломанной настройки, но я могу описать особенности:

• IIS, работающий на Windows Server 2008 r2, на котором размещено основное приложение asp.net с использованием ANCM.
• сервер сборки тоже 2008r2, на том же домене
• Сервер IIS имеет общий физический каталог веб-сайта с использованием общего доступа к Windows
• пользователь домена (учетная запись сервера сборки) запускает скрипт powershell на сервере сборки
  если этот скрипт использует команду копирования Windows для копирования в app_offline из существующего файла в другом каталоге, то процесс хостинга не останавливается. если сценарий вместо этого использует «эхо» (это может быть /bin/echo из установки mingw, я не уверен), то процесс хостинга закрывается.

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

@gulbanana Просто чтобы прояснить, вы пытались использовать команду dos copy, а не командлет power shell copy-item? Я не думаю, что пробовал обычную копию DOS, но обнаружил, что любое приложение на основе .net, которое я использовал, не работает.

если у powershell нет псевдонима для этого, это была копия dos

В моем случае копия PowerShell не остановит процесс dotnet.exe, но эхо, которое является псевдонимом Out-Content, работает. Я чувствую, что это вряд ли проблема .NET, но больше о том, почему сетевая копия не работает.

Я исследовал, есть ли какие-либо проблемы в уведомлении об изменении aspnetcore.dll (ANCM), но мне не удалось воспроизвести проблему, когда я попытался удалить app_offline.htm вручную либо с помощью командлета powershell, либо с помощью команды DOS. И я нашел один недостающий момент, который здесь не обсуждался.
Это что касается изящного выключения. В отличие от HttpPlatformHandler, ANCM поддерживает плавное завершение работы, что означает, что когда app_offline.htm удаляется в корневом каталоге, ANCM отправляет сигнал Ctrl-C/Break серверному процессу и ждет, пока не произойдет 10-секундное завершение работы.
10 секунд — это значение по умолчанию, и пользователи могут настроить это значение с помощью параметра shutdownTimeLimit в настройках конфигурации ANCM. Если внутренний процесс не остановлен в настроенный параметр shutdownTimeLimit, предполагается, что ANCM завершит работу внутреннего процесса.

Проверяя, как публикация MSDeploy связана с корректным завершением работы ANCM, я, наконец, нашел один последовательный шаг воспроизведения, который заключается в увеличении времени завершения работы (5 секунд), и заметил, что MSDeploy повторяет попытки только 2 раза по умолчанию и ждет всего 2 секунды и в конечном итоге не может опубликовать потому что он не ждет изящного завершения работы.

@vijayrkn
После того, как я установил 5-секундную задержку как для запуска, так и для завершения веб-приложения aspnetcore, я смог воспроизвести ту же ошибку, о которой сообщалось в этом выпуске, во втором испытании публикации веб-приложения aspnetcore на локальном сервере IIS. Я также прикрепил профиль публикации, который использовал ниже.
Не могли бы вы объяснить, почему это происходит, и дать правильное руководство по устранению этой проблемы с публикацией? И, пожалуйста, создайте новую проблему по этому вопросу отдельно, чтобы ваша команда отследила эту проблему, чтобы улучшить взаимодействие с пользователем.

... <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <WebPublishMethod>MSDeploy</WebPublishMethod> ...

MSDeploy пытается выполнить развертывание сразу после удаления app_offline. Если есть задержка с остановкой процесса, развертывание может завершиться ошибкой.

Счетчик повторных попыток для развертывания можно задать с помощью этого свойства msbuild (https://github.com/aspnet/websdk/blob/dev/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/PublishTargets/Microsoft .NET.Sdk.Publish.MSDeploy.targets#L67)

например, установка для этого свойства значения 10 гарантирует, что msdeploy повторит попытку 10 раз с задержкой в ​​одну секунду между ними.
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

Спасибо за информацию. После добавления двух строк ниже я не вижу никаких проблем с той же средой воспроизведения.
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

Таким образом, любой, кто сталкивается с подобной проблемой, должен будет увеличить счетчик RetryAttemptsForDeployment с соответствующим значением и повторить попытку, если это может решить проблему.

ПРИМЕЧАНИЕ. Причина, по которой я добавил EnableMSDeployAppOffline, заключается в том, что он отключен по умолчанию при использовании локального сервера IIS в качестве места назначения публикации веб-приложения aspnetcore. Итак, если вы не уверены, включено ли это в вашей среде, вам просто нужно будет добавить строку, и поэтому я добавил ее здесь для вашей информации.

Просто для того, чтобы исходная проблема не потерялась из-за самых последних обсуждений, проблема, с которой столкнулась моя команда, определенно не связана со временем. Мы протестировали ручное создание файла app_offline.htm как с помощью Powershell, Fake, так и с помощью проводника файлов на базе .Net под названием «Nomad», и процесс не останавливается независимо от того, как долго вы ждете. Создание файла с помощью File Explorer, пакетного файла DOS или сценария bash (т. е. процессов, не основанных на .Net-библиотеке) приводит к завершению процесса в течение 1-2 секунд.

Казалось бы, это указывает:

1. Проблема не связана с сетью (все тесты проводились на удаленном файловом ресурсе)
2. Это не проблема изящного выключения/времени

Тот факт, что 3 не-.Net-метода создания файла app_offline.htm надежно и быстро останавливают процесс и что 3 .Net-библиотекообразных метода создания файла никогда не приводят к остановке процесса в наших тестах, кажется действительно , действительно большой показатель для меня.

@derekgreer
Я не могу воспроизвести проблему даже с «Кочевником».
Вот что я сделал на своем компьютере с Windows 10 (amd64).

1. Установить IIS
2. Установите визуальную студию 2017.
3. Создайте веб-приложение AspnetCore и разверните его на локальном сервере IIS с помощью MSDeploy.
4. Установите Nomad v3.2.0.2890 (http://www.nomad-net.info/downloads)
5. Отправить запрос в веб-приложение
6. Откройте диспетчер задач и убедитесь, что процесс dotnet.exe запущен.
7. Откройте Nomad и создайте новый файл с именем app_offline.htm в корневом каталоге веб-приложения.
8. Просмотрите диспетчер задач и убедитесь, что процесс dotnet.exe исчез при создании файла app_offline.htm.

Не могли бы вы указать точные шаги воспроизведения, чтобы я мог воспроизвести проблему?

Помимо того факта, что наше приложение .Net Core на самом деле является стандартным консольным приложением .Net 4.5.2, созданным в VS 2015, которое ссылается на сборки ASP.Net Core, я не вижу никакой разницы. Проекту уже около года, и в то время он был настроен таким образом из-за ограничений, связанных со ссылками на типы проектов основных шаблонов из типов проектов шаблонов .Net framework и различными видами поддержки библиотек тестирования для ядра .Net.

Мы выявили пару проблем: 1) удаление файла app_offline.htm (с помощью какого-либо инструмента) иногда вызывало только уведомление об изменении свойства файла, которое было отфильтровано ANCM. 2) ANCM мог не прочитать app_offline.htm, так как последний удерживался инструментом копирования файлов. 3) корректное завершение работы вызвало задержку завершения серверного процесса.
Мы рассмотрим первые две проблемы в следующем выпуске. Для корректного завершения работы пользователю необходимо повторить попытку.

звучит неплохо. мой случай определенно не касался изящного тайм-аута выключения - когда он останавливается, он останавливается немедленно.

Есть новости по этому вопросу?
Получение при попытке развернуть приложение ASP.NET Core 1.1 в слот веб-приложения Azure с помощью VSTS

• У меня стоит MSDEPLOY_RENAME_LOCKED_FILES=1 в настройках приложения
• Задача «Управление службой приложений» настроена на перевод приложения в автономный режим.
• Задача «Развертывание службы приложений» _была_ настроена на перевод приложения в автономный режим, но это тоже не сработало

Основная проблема заключается в том, что DLL используется:

@ChuckkNorris, пожалуйста, смотрите https://github.com/Microsoft/vsts-tasks/issues/1607 , чтобы узнать последние новости.

@davidebbo Спасибо за ответ, Дэвид. Я видел эту ветку, и именно там я обнаружил множество обходных путей, которые пробовал.

Поскольку эта проблема все еще остается открытой и ошибка по-прежнему распространена, я надеялся, что скоро будет исправление, а не другой обходной путь. В конце концов, этот вопрос открыт уже более двух лет.

@ChuckkNorris , хотя симптом тот же, это не та же проблема:

• Первоначальная проблема, связанная с регистром app_offline.htm , приводила к полному его игнорированию. Это было исправлено на некоторое время.
• Эта новая проблема началась примерно неделю назад и возникает из-за того, что теперь Core требует больше времени для завершения работы при создании app_offline.htm , а msdeploy по умолчанию не ждет достаточно долго. Обходной путь — увеличить количество повторных попыток.

Я только что обновил VS 2017 до 15.3 и установил .NET core 2.0 SDK. Создал простое приложение MVC в VS - оно было нацелено на netcoreapp1.1. Я опубликовал в Azure, и все было в порядке. Я обновился до newcoreapp2.0, а затем обновил все пакеты nuget до 2.0 (Microsoft.AspNetCore, Microsoft.AspNetCore.Mvc и т. д.).

При попытке опубликовать в Azure (т.е. перезаписать 1.1) я получаю это

Error : Web deployment task failed. (Web Deploy cannot modify the file 'Microsoft.ApplicationInsights.AspNetCore.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)

@DaveSlinn см. https://github.com/Azure/app-service-announcements/issues/24

Мне пришлось отключить MvcViewComplication, чтобы мои приложения 2.0 развертывались через git и предотвращали проблемы с использованием файлов.

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment-349115532
@davidebbo , мы можем закрыть этот вопрос?
Несмотря на добавление помощника повторных попыток для веб-развертывания, эта проблема сохраняется.

Просто хотел указать на очевидное, что это также влияет на публикацию на FTP.

@jeremycook FTP немного отличается, так как не имеет автоматизации для использования App_Offline. Вам нужно будет вручную создать этот файл, чтобы завершить процесс, после чего вы сможете копировать файлы.

@davidebbo достаточно честно, но похоже, что если я опубликую через FTP, используя функцию публикации Visual Studio, это должно просто работать. Может я не туда пишу?

@jeremycook , честно говоря, я не уверен, что делает VS при развертывании FTP. Может быть, другие могут проявить себя, но это больше похоже на вопрос VS, чем на ASP.NET.

Хотя, чтобы изолировать, было бы интересно проверить, успешно ли развертывание, если вы вручную создаете App_Offline.html, а затем публикуете FTP из VS.

@vijayrkn Можете ли вы прокомментировать поведение VS во время развертывания FTP?

FTP-публикация из VS в службу приложений не поддерживает App_Offline.

@vijayrkn хорошо, поэтому для всех практических целей мы можем сказать, что развертывание .NET Core через FTP не поддерживается, если только пользователь явно не остановит сайт перед развертыванием. Верно?

@davidebbo - Да, это правильно.

Возникновение этой проблемы при развертывании веб-приложения asp.net core 2.0 в IIS из выпуска VSTS с использованием шаблона веб-развертывания IIS. Удалить не удается из-за используемого файла. Автономный режим приложения включен.

@davidebbo @vijayrkn @shirhatti все это немного угнетает. Планируется ли заставить работать FTP/XCOPY? Должен ли быть открыт новый выпуск, посвященный развертыванию по старинке через FTP/XCOPY/ROBOCOPY/и т. д.?

Я опаздываю на эту вечеринку, но вот несколько моментов, о которых я хочу сообщить:
VS 2017 Предприятие
asp.net 4.6.xx
сервер IIS 8.5 на сервере 2012 R2
Типы dll серверов sql заблокированы, и блокировка такова, что когда другой разработчик публикует с помощью msdeploy, они получают сообщение об ошибке, и веб-сайт теперь не работает, поскольку выполнялась только часть развертывания.

DLL-файлы типов sql заблокированы в папке bin приложения и только в них.
переименуйте файлы dll, а затем я могу опубликовать.
упаковка типов sql содержит код для загрузки неуправляемых dll.
кажется, что это должно быть изменено, чтобы не блокировать их. если это можно сделать.

Я видел, как люди говорили о способах перезапустить сайт или перевести его в автономный режим, но я не нашел для этого настройки в msdeploy. xml, который я видел, отсутствует в моих файлах.

в пакет типов sql, который публикует Microsoft, следует добавить лучшее руководство.

Публикация по этому вопросу, поскольку он кажется более непосредственно связанным с моим. Я также следил за приведенной ниже проблемой по той же теме, хотя она предназначена для VSTS. Я публикую прямо из визуальной студии.

https://github.com/Microsoft/vsts-tasks/issues/5259#issuecomment-350940342

Эта проблема была для меня время от времени, но недавно вернулась в силу, и на одном из моих сайтов службы приложений я получаю эту ошибку почти при всех попытках публикации. Этот сайт размещен в сервисе «базового» уровня, поэтому у меня нет слотов, которые я использую в других приложениях, чтобы обойти эту проблему.

Это для приложения .net core 2 mvc.

Одна мысль: некоторые файлы, являющиеся частью веб-приложения, не изменяются при каждой публикации (например, типы sql).
но ms deploy пытается заменить их при каждом развертывании.
похоже, что должна происходить какая-то проверка, чтобы не было повторного копирования файла, который не изменился, и это сделало бы обновление меньше и быстрее, и меньше нужно возиться с блокировкой файла.
многочисленные преимущества, если это можно сделать.

другое дело - лучше определить, что блокирует файл, почему и как это отменить.
и получите это как часть стандартного конвейера развертывания.

@figuerres Я хотел решить эту проблему уже пару месяцев. Проблемы с блокировкой обычно избегаются благодаря теневому копированию, но при загрузке этих собственных библиотек DLL из ~/bin возникает проблема с блокировкой. У меня есть потенциальное решение, но я не уверен, что это полностью безопасное решение: https://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to- каталог теневого копирования

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

@figuerres К вашему сведению, я реализовал вышеизложенное, код см. в вопросе о переполнении стека.

Убить dotnet.exe в диспетчере задач

Какой тут статус? Прошло 3 года, до сих пор не исправили. Мне приходится вручную заходить на сервер и останавливать сайт.

3 года? О проблеме было сообщено в августе 2017 года. Отключено на 1 лайк.
В понедельник, 23 апреля 2018 г., в 20:56 Оливер Яник[email protected]
написал:

Какой тут статус? Прошло 3 года, до сих пор не исправили. я должен вручную идти
на сервер и остановить веб-сайт.

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
.

В самом первом посте написано "Пекках открыл этот выпуск 23 июня 2015 года".

Ты прав. Моя вина. Я видел только последнюю метку времени в цепочке электронной почты.
В понедельник, 23 апреля 2018 г., в 21:06 Оливер Яник, [email protected]
написал:

В самом первом посте написано "Пекка прокомментировал 23 июня 2015"

—
Вы получаете это, потому что вы прокомментировали.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
.

Закрытие, потому что это так же старо, как грязь 😄

@Eilon Извините, но почему это было закрыто? Это все еще не решено?

Закрытие, потому что это так же старо, как грязь 😄

Но это все еще проблема .. ? (даже при развертывании без лазури)

Создан новый выпуск (#3719) для повышения видимости.