Aspnetcore: 使用中のファイルが原因で展開が失敗する

Azure VMでのIISファイルのロックで、WebDeployの展開を妨げる同様の問題に気づきました。 私の回避策は、3つのWebDeployコマンドを発行することです。AppPoolを停止し、デプロイし、AppPoolを再起動します。 私のスクリプトを参照してください; また、3つのWebDeployコマンドを実行できる場合は、AzureAppsで同様のことができる可能性があります。

beta6でこの問題が発生します。

こっちも一緒！ これにより、Visual Studio 2015が実際にフリーズします-vNextアプリを公開するとき（beta6とbeta7の両方だと思います）。

展開を行うためにMicrosoftが提供するスクリプトを使用していますか？ その場合は、 PublishAspNet5Website.ps1に行を追加するだけで、Webアプリを再起動できます。

Restart-AzureWebsite -Name $websiteName

この投稿でビルドスクリプトの変更の概要を説明します： ASP.NET5の展開の問題をAzureWebAppSlotに解決する

@brandonmartinez 、Webサイトを再起動しても効果はありません。本番Webサイトはリクエストを受信し続けるため、ファイルが再ロックされます。 現在、IISとAzureの両方のWebサイトを更新する唯一の信頼できる方法は、Webサイトのアプリケーションプールをシャットダウンし、ファイルを更新してから、Webサイトを再起動することです。 詳細については、 @GuardRexのリンクをたどってください。

ただし、VS2015でデフォルトの条件で作業する場合は、カスタム展開スクリプトをいじくり回す必要はありません。

新しいHttpPlatformHandlerインフラストラクチャ（AspNet.Loader.dllは不要になりました）がもう少し寛容になることを願っていますが、ここでは息を止めていません。 おそらく別のロックされた.dllを取得します。

@rubenprinsこれは、VSのAzureSDKツールを介して私も使用する回避策です。

VMへの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を停止し、デプロイして、再起動するだけで安定しています。ワーキングアプローチ。

VS2015でデフォルトの条件下で作業する場合、カスタム展開スクリプトをいじくり回す必要はありません。

ただし、「ファイルシステムに公開」を使用でき、公開直後にMSDeployビットを含むスクリプトをフックできることで、複数のVMの非常にシンプルで便利な展開ストーリーが可能になりました。 スクリプトは順番に実行されるため、VMからVMへとすぐに移動します。 素敵なコーヒーブレイクになります。 ：笑顔：

AzureResourceManagerチームでAzureResourceManagerを使用してインターネット向けロードバランサーの構成を開始するときに、デプロイ中にVMへのトラフィックの送信を一時的に停止するようにロードバランサーに指示する方法について質問があります。

とにかく... @pekkahが提起した目前の主題に戻ります。 PSコマンドが機能することがわかっているので、VSOビルドでそれらを実行するためのオプションを確認します。

Microsoft /vso-agent-tasks
ビルドプロセスでスクリプトを実行する
Azure継続的デプロイビルドプロセス用のTeamFoundationService（Visual Studio Online）でのビルド前スクリプトの実行
VisualStudioOnlineの新しいビルド自動化機能

...ええ...そのようなものがあなたのために働くはずです。

ここで同じ問題...

まだ公式の解決策を待っています

ブルーノ

これはhttps://github.com/aspnet/IISIntegration/issues/81で解決されます。

@moozzyk 、この問題は、msdeployなどの専用ツールを介したデプロイメントのみを修正します。 Xcopy / File Syncの展開はまだ不可能であり、ASP.NETv1-4でのみ機能する多くのCIシナリオをブロック/妨害します。

この問題は、サーバー用の最新ツールを備えたWindows2012R2上のIIS8へのVisualStudio2015.2MSDeployを使用したASP.NETCore1.0RC2に引き続き存在します。 dotnet.exeプロセスを強制終了するか、アプリケーションプールをリサイクルすると、問題が解決します。 ただし、これにはサーバーへのリモートデスクトップアクセスが必要であり、正確にスムーズなプロセスではありません。

@dg9ngf-これはweb.deployのバグです。 Azureにapp_offline.htm機能が追加されましたが、ローカルにデプロイするとデフォルトで無効になります。 公開プロファイル（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>

そのプロパティは、VisualStudioが作成した.pubxmlファイルには存在しませんでした。 それで追加しましたが何も変わりませんでした。 -e nablerule：AppOffline引数は、出力ウィンドウに表示されません。

出力ウィンドウに表示されるmsdeployコマンドラインを共有できますか？

また、pubxmlに「MSDeploy」としてWebPublishMethodが含まれていることを確認できますか。
<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]

このブログ投稿で説明されているように、VSTSで「AzureWeb AppDeployment」タスクを使用してデプロイしています：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ステップを追加する必要があります。 特にデプロイメントスロットを使用していないため、理想的なソリューションからはほど遠い（実際にはかなり不十分です）が、開発/テスト環境では問題なく機能します。

msdeployベースで修正を約束するWebアプリデプロイメントVSTSタスクの新しいプレビューARMバージョンがありますが、サブスクリプションのサービスプリンシパルを作成するためにクライアントが必要だったため、運が悪かったです。面倒だった。 多分あなたはそれを機能させることができます：
https://github.com/Microsoft/vsts-tasks/tree/master/Tasks/AzureRmWebAppDeployment

@vijayrkn VS2015の[Webの公開]ダイアログには、msdeployを設定するオプションは含まれていません。WebPublishMethod=FileSystemのオプションのみが提供されます。

WebPublishMethod = msdeployのサンプル.pubxmlを提供できますか？

@tomfanning ASP.NETコアコンソールアプリケーションの場合、現在使用可能な公開オプションはファイルシステムのみです。 コンソールアプリケーションを公開しようとしていますか？ Webアプリの場合、これら4つのオプション（webdeploy、web deployパッケージ、ファイルシステム、およびftp）がすべて使用可能である必要があります。
サンプルwebdeploypubxml- https://github.com/dotnetpublish/AspNetCoreBlogList/tree/master/src/AspNetCoreBlogList/Properties/PublishProfiles

Webアプリで、ファイルシステムの公開オプションのみが表示されている場合、xprojをチェックして、これがインポートされるかどうかを確認できますか？
<Import Project="$(VSToolsPath)\DotNet.Web\Microsoft.DotNet.Web.targets" Condition="'$(VSToolsPath)' != ''" />

@bojingoサービスプリンシパルを設定することができました。ネット上にいくつかのチュートリアルがあります。 ここにはリンクがありませんが、必要に応じてリンクを探すことができます。 今私の問題は、タスクがASPNetCore公開で生成されないparameters.xmlファイルを必要とすることです...:(

私はTFS2015をオンプレミスで使用していますが、これは非常に厄介な問題です。

私もこの問題に遭遇しています...

私の解決策は、デプロイするステージングスロットを停止したままにして、公開することでした（自動スワップは機能します）。 再起動してからデプロイが機能しませんでした（VSTSを使用したデプロイ）

Azure Web Appsでタコを使用していますが、スロットをステージングするためのオプションがありません。 ただし、次のオプションをチェックすることは機能したようです。

• ルートに空白のapp_offline.htmlを使用して、アプリドメインを安全に停止します。
• デプロイメントの一部ではない宛先上のファイルを削除します

Visual Studio 2015 Update 3を使用して、asp.netコア1.1/.netフレームワーク4.5.2サイトをIISに公開しています。 App_Offline.htmをドロップダウンしますが、サイトはダウンしません。 サーバー上で名前をapp_offline.htmに変更すると、サイトがダウンします。

このように、app_offline.htmでは大文字と小文字を区別しないでください。

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

Deployerはapp_offline.htmをアップロードします（大文字と小文字は区別されません）

再度公開したところ、 App_Offline.htmが削除され、サイトがダウンせず、ファイルの使用中にエラーが発生しました。 app_offline.htmに変更すると、サイトがダウンし、エラーなしで公開できます。

私は共有UNCパスでホスティングしています-それが違いを生むかどうかはわかりません。

@Tratcher -App_Offline.htmの大文字小文字がここで違いを生む理由を知っていますか？

jayvijayrknhttps ://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 WebデプロイVSTSタスクがこれを処理したように見えましたが、今週末の時点で常にエラーが発生しています。 展開スロットを停止し、展開して、再開することに戻りました。

私たちと同様に、この問題は先週の金曜日に発生し、それ以降は展開できなくなりました...

こっちも一緒。 Always On = trueのサイトにのみ影響するように見えますが、それは確かではありません。

構成でMSDEPLOY_RENAME_LOCKED_FILES=1を設定した場合でも、この問題が発生します。 現在、サーバーのビルドを更新することはほぼ不可能です。 これは数日前に起こり始めたばかりです。

同じ問題が今週私にも起こり始めました。 今週まで、[アプリをオフラインにする]=trueに設定してVSTSにAzureRMアプリサービスをデプロイすることは一貫して機能していました。 現在、この設定は無視されているか、サービスが時間内にオフラインになっていないようです。 リリースを実行しているときに、アプリサービスを手動で再起動するか、停止/開始する必要があります。

ここで同じ問題。 AzureRmは数か月間機能していましたが、突然停止しました。 私の最後のデプロイは2週間前の12/5でしたが、現在は12/20にError_File_In_Useを生成しています。 手動のスタート/ストップに戻らなければならないのは非常に面倒です。

CI/ビルドプロセスの一部として現在使用しているPowershellの回避策は次のとおりです。 これを手伝ってくれた@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を利用して、正しくケースに入れられapp_offline.htmファイルをHTTP PUT ＃$配置します。 WebDeployは、デプロイメントに含まれていないファイルを削除するように構成されているため、デプロイメントの一部としてファイルを自動的に削除します。 このモードを使用していない場合は、展開が完了した後にファイルを削除するために、 HTTP DELETEを使用して手順を繰り返す必要がある場合があります。

AzureRMタスクの前にTrackyonStopを追加し、後でTrackyonStartタスクを追加することは私にとってうまく機能しています。 これは、TakeAppOffline = trueの場合は必要ありませんが、機能しており、手動またはスクリプトを回避します。 タスクをリリース定義に追加するだけです。 Trackyonステップは簡単に設定できます

2016年12月21日午前12時10分、ChadT< notifications @github.comnotifications@ github.com >は次のように書いています。

CI/ビルドプロセスの一部として現在使用しているPowershellの回避策は次のとおりです。 これについて助けてくれた@appveyorhttps://github.com/appveyorの人たちに特に感謝します：

$ username = $ env：deployusername
$ password = $ env：deploypassword
$ base64AuthInfo = [Convert] :: ToBase64String（[Text.Encoding] :: ASCII.GetBytes（（ "{0}：{1}" -f $ username、$ password）））
$ Headers = @ {
'承認'=（'基本{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 https://github.com/projectkudu/kudu/wiki/REST-APIを使用して、正しくケースに入れられたapp_offline.htmファイルをHTTPPUTします。 WebDeployは、デプロイメントに含まれていないファイルを削除するように構成されているため、デプロイメントの一部としてファイルを自動的に削除します。 このモードを使用していない場合は、展開が完了した後でファイルを削除するために、HTTPDELETEを使用してこの手順を繰り返す必要がある場合があります。

-
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/aspnet/Home/issues/694#issuecomment-268436959で表示するか、スレッドをミュートしますhttps://github.com/notifications/unsubscribe-auth/AID9WoUdbuBnFoXR2K5o8AiUtv8nE9dRks5rKLTc

このメッセージは非公開であり、特権情報、専有情報、または機密情報が含まれている可能性があります。 誤って受け取った場合は、すぐに送信者に通知し、オリジナルのコピーをすべて削除してください。 その他のお客様による電子メールの使用は禁止されています。 このメッセージの内容を許可なくコピー、保存、使用、または開示することは許可されておらず、違法である可能性があります。 現地の法律で許可されている場合、Litheroとの電子通信は、情報セキュリティおよびLitheroのポリシーと適用法の内部コンプライアンスの評価の目的で、当社のシステムによって監視およびスキャンされる場合があります。

/ cc @davidebbo

アプリのAzureアプリ設定でMSDEPLOY_RENAME_LOCKED_FILES=1を設定してみてください。

@davidebboこれは問題を解決していないようです。

これは、フェンスのAzure側の変更に関連していると思いますか？ 多くの人（特にaspnet slackチャネル）は、この問題をすべて同時に発生させています。

Azureでの変更では、TFSでこのオンプレミスが表示される理由を説明できません。 それはエージェントでしょうか？

同じ問題が発生しています。 App_Offline.htmは取得されません。 奇妙なことに、VSからデプロイすればうまく機能します。

奇妙なことに、ここで説明されているように、私にとってはVSからは機能しません：＃1883

私のチームもこの問題に遭遇します。ほとんどの場合、ファイルがロックされているために展開が失敗します。 Azureですべてのアプリを再起動し、デプロイを再実行する必要があります。 OctopusDeployを使用しています。

私のチームは今朝この問題に遭遇しました。 Microsoftチームからのコメントはありますか？ リリースパイプラインは私たちの生産性にとって重要であり、これが本番サイトへのリリースを妨げています。 ありがとう！

@bmoscao -app_offline.htmlでは大文字と小文字が区別されます。

この問題は、Azureでも発生しました。 それを引き起こすために私が最後にしたことは何もありません。

私もこの問題を抱えています。 問題は、 EnableMSDeployAppOfflineがtrueに設定されていることです。プロジェクトの出力には、Visual Studioによって実行されているコマンドの一部として-enablerule:AppOfflineが表示されます。 どうしたらよいかわかりません...この問題が発生し始めたのは最近のことです。

これに対する回避策は、アプリプールを停止し、デプロイしてから、アプリプールを再起動することでした。 これを実現するために、リリースマネージャーとインライン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からの入力は間違いなくありがたいですが、これは、RMAzureの展開ステップでappOfflineルールを有効にするだけでうまく機能していました。

@davidebbo ASP.NET Core、VSTSリリースマネージャー、およびスロット付きのAzureRmWebAppを使用しています。

@davidebboありがとう！ わたしにはできる ;）

私たちにも起こります-msdeploytoAzure。 それが同時に多くの人々のために不思議なことに始まったことを見てうれしいです-そしてそれは私たちだけではありません-しかし全体的に非常に安心ではありません！

MSの人々はこれを確認する必要はないと思います。おそらく彼らは何が問題なのかよく知っています。 いずれにせよ、ここでも同じです。 VSTSからの展開は、12月初旬に動作を停止しました。 現在、trackyonタスクを使用して停止/開始しています。

このスレッドを通過すると、エントリごとに、常に明確であるとは限りません。

1. 問題がAzureAppServiceまたはその他のホスティングに関連しているかどうか
2. 上記のようにapp_offlineの大文字小文字を変更しようとしたかどうか。 何人かの人々がそこで成功を報告したようです。
3. MSDEPLOY_RENAME_LOCKED_FILESが試されたかどうか。 繰り返しになりますが、何人かの人々がそれで成功したようです。

この問題が発生した場合は、シナリオが何であるか、何を試したかを明確にしてください。これを理解できるようになります。 ありがとう！

@davidebbo

Visual Studio / MSBuildを使用して展開しようとすると、ERROR_FILE_IN_USEというメッセージが表示されます。 タスクはサーバー上にApp_Offline.htmファイルを作成することですが、アプリを停止することはありません。

Web Deployを使用してapp_offline.htmファイルを作成すると、アプリが停止します。

これは私の設定です：

• サーバー：IIS 8、.NET Core Windows Server Hosting 1.1.0、およびWeb Deploy 3.6
• 私のマシン：Visual Studio 2015Update3および.NETCore1.0.1ツールプレビュー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

同様のスレッドでこのエラーについてコメントし、再デプロイするたびに（開発環境で）、AzureWebアプリを停止して再起動する必要がありました。 今週までこれを行う必要はありませんでした。 基本的に、テンプレートから変更を加えずにVisual Studio2015.netコアWebアプリを作成することにしました。

ローカルホストでWebアプリを実行しましたが、まったく問題ありません。
新しいアプリをAzureWebApp Service Planに問題なく公開すると、ブラウザーはすぐにサイトを問題なく起動しました。
Azureダッシュボードを確認しましたが、まったく問題ありませんでした。

次に、コードや設定などを何も変更せずにWebアプリにアクセスして再公開しましたが、次のエラーが表示されます。

それ以降は、Webアプリを停止し、Azureに公開してから、Webアプリを起動する必要があります。 これは私には今までに一度も起こりませんでした。 これは、Microsoftテンプレートの非常に単純な展開です。

このプロセス全体を記録し、そのフィードバックをMicrosoft2015VSフィードバックシステム内に送信しました。 あなたがその録音を見つけることができることを願っています。 または私はおそらく再びそれを行うことができます。

よろしくピーター

@davidebbo

問題がAzureAppServiceまたはその他のホスティングに関連しているかどうか

AzureAppService。

上記のようにapp_offlineの大文字小文字を変更しようとしたかどうか。 何人かの人々がそこで成功を報告したようです。

App_Offlineをapp_offlineに変更すると、問題が修正されます。このファイルは、問題の核心であるデプロイメントの一部として「App_Offline」ケーシングを使用して、webdeployを介して自動的に作成されます。

@davidebbo
@ctolkienとまったく同じです。

@davidebbo

問題がAzureAppServiceまたはその他のホスティングに関連しているかどうか

私の場合、AzureAppServiceにデプロイしています。 他のホスティングについては知りません。

上記のようにapp_offlineの大文字小文字を変更しようとしたかどうか。 何人かの人々がそこで成功を報告したようです。

VSTS（https://aka.ms/azurermwebdeployreadme）の「DeployAzureRMWebApp」タスクを使用しています。 「WebDeployを使用して公開」<-チェックおよび「アプリをオフラインにする」<-チェックされたオプションがあります。これは、どこかで何かが変更されて機能しなくなるまで機能していました。
「info」ツールチップは、「app_offline.htm」を小文字の「a」で配置することを明示的に示しています。
このスクリプトを使用して変更する方法がわかりません。すでに小文字になっているはずです。

MSDEPLOY_RENAME_LOCKED_FILESが試行されたかどうか。 繰り返しになりますが、何人かの人々がそれで成功したようです。

試していません。 それを行う方法がわかりません。 ただし、いずれの場合も、ロックされたファイルの内容を変更するのではなく、アプリをオフラインにすることをお勧めします。

皆さんありがとう。 したがって、主な問題はapp_offline.htmのケーシングにあり、Azure App Service（私が所属している側）に関連するものではないことは明らかです。 そして、これはhttps://github.com/aspnet/AspNetCoreModule/issues/50によって追跡されます。

この問題を閉じて、他の問題を維持することをお勧めします。 Azure Web Appが部分的に責任があると考える理由がない限り、ASP.NETの専門家にそれを任せます（ @fabianoがAzureの外部で同じことを報告しているとは考えられません）。

実際、これは、app_offline.htmlではなくApp_Offline.htmlの作成を開始したように見えるツールのリグレッションのように見えます。 @ mlorbetske 、 @ vijayrkn-それが何であるかについて何か考えはありますか？

わかりました。コアランタイム（AspNetCoreModule）は常に大文字と小文字を区別していましたが、VSが一致する大文字と小文字を使用していたため、問題にはならなかったとおっしゃっていますが、現在はそうではありませんか？

とはいえ、ここではランタイムで大文字と小文字を区別するべきではないと主張します。そのため、この問題に対処するための2つの可能な方法があります。

@davidebbo-これは正しいです。 AspNetCoreModuleは常に大文字と小文字を区別していたと思います。

@davidebbo

Azure App Service（私が出身である側）に関連するものは何もありません

Azure AppServiceを議論に取り入れた理由は、私たちに代わって変更を加えることなく、問題が発生し始めたばかりであり、パッケージのバージョンを変更しなかったためだと思います。 ANCMリビジョンはAppServicesで改訂されましたか？

@ctolkienはい、確かに更新されたと思います。 したがって、上記の結論が正しくない可能性があります。 代わりに、新しい理論は次のとおりです。

• 古いANCM（7.1.1965.0）では、大文字と小文字は区別されませんでした。
• 新しいもの（7.1.1970.0）では大文字と小文字が区別されました。
• VS公開側では何も変更されておらず、ケーシングは常にApp_Offline.htmた。

@moozzykそれは可能性があると思いますか、それとも常に大文字と小文字が区別されると確信していますか？

@moozzyk@ davidebbo -app_offlineケーシングのVSツールに変更はありませんでした。 VSツールはappofflineルール（-enablerule：AppOffline）を使用してmsdeployを呼び出し、msdeployはApp_Offline.htmをドロップします。

この問題は、ANCMでの動作の変更のように見えます。 ここでの最初のコメントに基づいて、app_offlineでは大文字と小文字を区別しないようにする必要があります（https://github.com/aspnet/IISIntegration/issues/81）。

@ctolkien

App_Offlineをapp_offlineに変更すると、問題が修正されます

これはどこで変更できますか？ VisualStudioからAzureに直接MSDEPLOYを実行します。

@oyvindvol

これはどこで変更できますか？ VisualStudioからAzureに直接MSDEPLOYを実行します。

私の知る限り、MSDEPLOYからApp_Offlineの大文字小文字を変更することはできません。今のところ、ソリューションをカスタムスクリプト化する必要があります。 上記で投稿したPowerShellスクリプトを出発点として使用できます。

全員を更新するために、上記の理論が正しいことを確認しました。大文字と小文字の区別のバグはANCMの新しいバージョンでのリグレッションであり、そのバージョンは12月にAzure App Serviceにデプロイされ、ユーザーが突然これに遭遇しました。

計画は、ASP.NET CoreチームからANCM修正を取得し、それをAppServiceに展開することです。 ETAはまだありませんが、1月中に発生するはずです。

ありがとう！

@davidebbo ANCMをダウンロードして、iisを使用して独自のサーバーにインストールし、この特定のバグも発生させることができますか？

@Pictuelそう思います。 ここでの私の見解は厳密にAzureAppServiceであるため、コアチームにAzure以外のシナリオについてコメントさせます。

ヘッドアップをありがとう ：）

@Pictuelはい、ANCMの更新を含む.NETCore用のWindowsホスティングインストーラーの更新バージョンがリリースされることを確認します。

@shirhatti

@shirhatti更新されたインストーラーがドキュメントリンクを更新できるようになると、ここで監視しています。

そのスレッドを通過した後、AppServicesの回避策が正確に何であるかはよくわかりません。 それはアプリの設定ですか、それともカスタム展開スクリプトを使用していますか、それともサイトを停止して開始していますか？

それがアプリの設定である場合、Webサイトが新しいDLLを取得しない原因になるという別のコメントを読みました。

私が正しく理解していれば、ANCM（https://github.com/aspnet/AspNetCoreModule/issues/50）で更新が利用可能になるまで、回避策はありません。 アプリサービスは、Azureチームが更新する必要があります。

App Serviceに最善を尽くすのは、 @dtmnashで説明されているようにアプリを停止/開始することだと思います。

@davidebbo 「計画では、ASP.NET CoreチームからANCM修正を取得し、それをApp Serviceに展開します。ETAはまだありませんが、1月中に発生するはずです。」 --ETAの準備ができたらお知らせください:)

暫定展開ETAは24日から30日の間です。 展開は多くのスケールユニットで徐々に行われるため、全員が同時に修正を取得できるわけではありません。

ありがとう、私にとってそれはちょうど働き始めました:-)

まだ私にとっての問題:(

@hbunjes確認してくれてありがとう！

@rsnjそれはある期間にわたって徐々に起こっています。 すべては月末までに完了する必要があります（問題が発生した場合を除く）。

@davidebbo配置は、私のアプリの一部で機能するようですが、すべてではありません。 奇妙なことに、一部の展開は失敗しますが、同じAppServicePlanで実行されているアプリでは失敗する展開もあります。 特定のWebアプリで実行されているANCMのバージョンを確認することはできますか？

@henningst確認方法については、 https： //github.com/aspnet/AspNetCoreModule/issues/50#issuecomment-271381892を参照してください。

昨日は働いていませんでしたが、今は働いています。 ありがとう@davidebbo！

それは私のためにも働き始めました。 ありがとう！

はい、これで展開が完了したので、すべての人に役立つはずです。

ここでも私にとってはすべて良いことです。

現在動作しているようです。 レポートから、これを修正するのに1年以上かかりました。 展開の問題の優先度は高くなりますが：p

Azure以外でこれを修正するにはどうすればよいですか？

@pekkah私はそれが明確な問題を経験したと思います。 最新のものは1年よりずっと最近のものでした。

Azure以外の場合は@jdshkolnik 、新しいANCMの使用を開始する必要があると思います。

@jdshkolnik
アップデートはhttps://www.microsoft.com/net/download/core#/runtimeからダウンロードできます。
これはダウンロードへの直接リンクです。

@shirhattiこれをインストールしましたが、まだこれらのエラーが発生しています。

南ブラジルのサンパウロでまだエラーが発生しています。

@jdshkolnik PowerShellでこれを実行すると、どのバージョンが表示されますか？

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

@shirhatti 7.1.1971.0

更新：申し訳ありませんが、これは私のせいでした。 リリース定義ではなく、既存のリリースの展開手順を確認して更新していました。 私はこれを何回行ったかのカウントを失いました...

私のバージョンのaspnetcore.dllが修正されていると思われるバージョンであるにもかかわらず、展開しようとするたびにこのエラーが発生します。

aspnetcore.dllバージョン：7.1.1971.0
デプロイ方法：VSTSタスクAzure App Service Deploy v3。*（プレビュー）
アプリをオフラインにする：チェック済み
宛先で追加のファイルを削除する：チェック済み
ロックされたファイルの名前を変更する：チェック済み
MSDEPLOY_RENAME_LOCKED_FILESアプリ設定：追加されていません

この段階では、これが機能するために必要な設定と不要な設定がわかりません。

Azureアプリサービスで最初のファイルが再び使用されました。

2017-02-14T22：41：10.4400186ZC：\ Program Files（x86）\ IIS \ Microsoft Web Deploy V3 \ msdeploy.exe --source ：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詳細情報：Web Deployは、外部プロセスによってロックされているため、宛先のファイル'Ascend.Ammo.Portal.exe'を変更できません。 公開操作を成功させるには、アプリケーションを再起動してロックを解除するか、次回の公開試行で.NetアプリケーションのAppOfflineルールハンドラーを使用する必要があります。 詳細については、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-server-hosting-bundle。

また、ランタイムダウンロードページでは、LTSバージョンのみが修正されているように見えますか？

@ shirhatti〜新しいホスティングバンドルインストーラーリンクの準備ができたらお知らせください。ドキュメントに掲載します（いくつかの場所にあります）。

〜これですか： https ：//go.microsoft.com/fwlink/？linkid = 837808 ...これはaka.msリンクではありません。〜

https://github.com/aspnet/Docs/pull/2773を設定して、fwlinkに問題がない場合にこれをカバーします。

Visual Studioでも発生し、オプションが示すように、アプリのオフラインルールが存在します。

@davidebboこれが修正されていることを確認できますか？ かなりの数の人々から、彼らはまだそれを打っていると聞いています。 ツールのリリースバージョンにはこれに対する修正がありましたか、それともホスティングの問題ですか？

私はまた、それがいつ、なぜ起こるのかを理解しようとしています。 プロセスがscmサイトのProcessExplorerで実行されており、正常に公開されていることをほぼ確認できました。

この問題が古いproject.jsonツールに関連していることを期待して、サイトを最新のツールに更新しているところです。

修正はしばらく前にAzureAppServiceに展開されましたが、その後も問題が発生している人は誰もいません。 もちろん、Azure以外のホストのユーザーは、更新されていない場合でも表示される可能性があります。

Azureの場合、問題が発生している場合は、次のようにテストしてください。

• Kuduプロセスエクスプローラーに移動し、アプリのプロセスが実行されていることを確認します（通常はdotnet.exe）
• Kuduコマンドからapp_offline.htmファイルを手動で作成します（例： touch app_offline.htmを実行します）
• Process Explorerをもう一度確認し、プロセスが存在しないことを確認します。

もう少しテストします。いくつかの投稿の画像を見ましたか。ファイルが使用中であり、アプリをオフラインで使用していることを明確に示しています。

しかし、私はあなたが尋ねたようにテストします。

また、仮想アプリケーションにデプロイされたスケールアウト+アプリを使用しています-それが何かを変えるかどうかはわかりません。

@pksorensenが「手動で」実行すると、WebDeployが実行している可能性のあるものから分離するのに役立ちます。 つまり、 app_offline.htmをドロップしてもプロセスが停止しない場合は、WebDeployが原因ではない問題があることがわかります。

通常、最終的にはdotnet.exeプロセスになりますが、この場合は別のexe名を使用していることに注意してください。 それはどういうわけか問題に関係しているのだろうか。

1. Kuduプロセスエクスプローラーに移動し、アプリのプロセスが実行されていることを確認します（通常はdotnet.exe）
   私はこれを行いましたが、それはdotnet.exeではなく、私たちの名前はbinAscend.Ammo.RegistrationTablet.exeをコンパイルしました

次に、app_offline.htmにタッチしましたが、これでプロセスが強制終了されませんでした。

dotnet.exeが表示されないので、何か問題がありますか？

dotnet/ANCMの専門家にその部分についてコメントさせます。 デフォルトでは、コアASP.NETアプリを展開するときに、dotnet.exeを使用します。 そうでない場合は、スタンドアロンのデプロイ（またはそれが呼ばれるもの）を使用する場合だと思います。 しかし、それがANCMとapp_offline.htmにどのように影響するかはわかりません。

@DamianEdwards誰がこれについて最もよくコメントできますか？

デプロイメントスロットを使用して、この問題を回避します。 100％の時間動作します。 ファイルをコピーする前にスロットを停止してください。 これにより、メモリからすべてが削除されるため、コピーはロックされたファイルでは機能しません。 次に、スロットを開始し、本番環境にスワップします。 顧客がアプリのオフラインページを決して見ないという追加の利点。 ダウンタイムの展開は0になります。

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

@DarqueWarriorスロットはもちろん機能します（そして他の理由で使用するのが良いです）が、このスレッドで重要なことは、@pksorensenのような一部の人々のコアプロセスをシャットダウンするのにapp_offlineが効果がないように見える理由を理解することです。 そして、コアチームにコメントしてもらいたいと思います。

@davidebbo以前の質問に答えるために、ポータブルとスタンドアロンはapp_offlineの動作とは関係ありません。 アプリのオフラインファイルは、w3wp.exe（ASP.NET Coreモジュール）によって監視されます。

@DarqueWarriorアドバイスに感謝しますが、コメントが1つあります。同じアプリサービスの仮想アプリケーションに複数のサイトをデプロイしている場合、スロット（正しいことを思い出すと）はそれらすべてで機能するため、前にすべてのサイトをデプロイする必要があります。スワッピング。 これは面倒です。 現在、パーツ（マイクロサービス）を個々の仮想アプリケーションに簡単にデプロイできます。 それらを別々のアプリサービスに分散させることはできますが、同じドメインを再び共有するためにロードバランサー/ゲートウェイを前面に配置する必要があります。また、現在実行するよりも多くの時間がかかります。

だから私はあなたの提案が好ましい方法であることに同意します、それは今私たちに合わないだけです。 したがって、使用中のファイルの問題の解決をまだ望んでいます。

@pksorensenダミーサイトに再現を設定してその名前を共有できる可能性はありますか？ 基本的には、サイトが実行されている状態で表示したいのですが、Kuduコンソールでapp_offline.htmを手動で作成しても、サイトがシャットダウンすることはありません。

@shirhatti ANCMがプロセスをシャットダウンしない原因となる可能性のあるアイデアはありますか？ それはどれほど積極的にそれを行おうとしますか？

@davidebbo少し時間がかかりますが、再現を作成するために何かを解決しようとします。

@davidebbo新しいASP.NETCoreアプリと新しいAzureAppServiceを作成しました。 Azureの「継続的デリバリー（プレビュー）」機能を使用していますが、この問題が発生しています。

2017-03-30T02：54：36.5648892Z##[エラー]AppServiceのデプロイに失敗しました。
2017-03-30T02：54：36.5658893Z ## [エラー]エラーコード：ERROR_FILE_IN_USE
2017-03-30T02：54：37.1850861Z詳細情報：Web Deployは、外部プロセスによってロックされているため、宛先のファイル'myApp.dll'を変更できません。 公開操作を成功させるには、アプリケーションを再起動してロックを解除するか、次回の公開試行で.NetアプリケーションのAppOfflineルールハンドラーを使用する必要があります。 詳細については、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

D：\ home \ site \ wwwrootにapp_offline.htmを手動で作成すると、実際にdotnet.exeプロセスが停止します。

それで、これは「継続的デリバリー（プレビュー）」自体に問題があることを意味しますか？

上記に加えて、VSTSリリース定義、追加の展開オプションに手動で移動し、[アプリをオフラインにする]にチェックマークを付けることで、これを修正しました。

しかし、これはいくつかの疑問を提起します：
「アプリをオフラインにする」がデフォルトでオフになっているのはなぜですか？ このシナリオは引き続き機能する必要がありますか（たとえば、ダウンタイムが短縮されますか）？

はいの場合、なぜ失敗するのですか？ いいえの場合、「継続的デリバリー（プレビュー）」がチェックされないままになるのはなぜですか？

いずれにせよ、どこかにバグがあるようです。

@ Jon12345 ：このスレッドは、app_offline.htmがコアアプリで正しく機能しているかどうかについてのみ説明しています。 そのため、VSTSがデフォルトでこれを実行している場合と実行していない場合は、実際には別の議論であり、VSTSフォーラム（おそらくhttps://social.msdn.microsoft.com/Forums/vstudio/en-US/ home？forum = TFService）。

この時点で、ほとんどの人は修正後にブロックが解除されたようです。 @pksorensenによって機能しないという報告が1つあり、リプロアプリが確認するのを待っています。

私はまだTFS2017Update1でこれを取得します。

@jdshkolnik appoffline.htmファイルを作成するように設定されていますか？ そうでない場合は、この問題の範囲外です。 上記のように、手動のappoffline.htmテストを実行してください。

@davidebboはい、そうです。 スケジュールされた夜間の展開が最初の試行に失敗し、通常は成功する手動の再展開の試行が必要になることがよくあります。

参考までに、私の会社はあなたの会社と連携しているので、SkypeforBusinessデスクトップ共有を介して簡単に紹介できます。

@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私がやったことが決定的なテストだったのかわかりません。 結局のところ、エラーが発生した後の2回目の手動試行は、通常は成功します。 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 App Servicesでアプリケーションを作成しましたが、それは1日中行われているので、一貫して言います。 これを引き起こしている可能性のある他のアイデアはありますか？

あまり。 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コンソールからこれを再現することはできません。 例えば

• Kuduコンソールに移動します
• $＃ D:\home\site touch app_offline.htmを実行して、別のフォルダーに空のファイルを作成します
• copy app_offline.htm wwwroot実行します。 これにより、最終書き込み時間が保持され、作成時間が更新されることに注意してください（標準のファイルコピー動作）。

結果：dotnet.exeプロセスは即座にシャットダウンします（Kuduプロセスエクスプローラーを使用して確認できます）。

これらの同じ手順はあなたのために働きますか？ もしそうなら、あなたの再現シナリオでは何が違うのでしょうか？

実際、この問題は断続的に発生しており、WindowsServer2012でIIS8を使用していることも付け加えておきます。

今朝の私の意図は、Kuduコンソールをセットアップする前に、PowerShellまたはバッチスクリプトで問題を再現できるかどうかを確認することでしたが、金曜日にチームがapp_offline.htmファイルを作成するために使用したテスト偽ビルドスクリプトで最初にテストしました。さまざまな方法（既存のファイルのコピー、新しいファイルの作成など）で、現在機能しています。 これは、ビルドの失敗のパターンを反映しており、プロセスをシャットダウンする場合とシャットダウンしない場合があります。 それが失敗し始めるとき、それは一貫してそうしているようです。 金曜日に何時間もテストしましたが、新しいapp_offline.htmファイルを作成する以外に何もしなかった単純なFakeビルドで一貫して停止することはありませんでした。 また、定期的に手動でファイルを作成し、プロセスが停止することを確認するため、長期間使用してもプロセスがシャットダウンしないような状況にはならないように思われることも付け加えておきます。

問題を再度再現できる場合は、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 Consoleは実行されないことを考えると、これはCLRを介して作成されているファイルに関連するものを指しているようです。

奇妙なことに、さまざまなバージョン間で、結果のファイルの作成/更新タイムスタンプに違いは見られません。

@derekgreerああ、AzureAppServiceをまったく実行していません。 これがこの物語全体における私の見解なので、ASP.NETの人々にこれについてさらにコメントさせます。

それだけの価値はありますが、AppServiceで再現することはできませんでした。

• KuduのPowerShellコンソールを使用する
• site\wwwrootフォルダーに移動します
• New-Item app_offline.htm -type file実行します

@moozzykは、 @ derekgreerのアプリ外部の再現を調査するのに役立ちますか？

詳細情報：

ファイルエクスプローラーを使用した作成、コピー、名前の変更などは一貫して機能しているため、.Netベースのファイルエクスプローラーアプリが、FakeやPowerShellで見たのと同じ結果を反映しているかどうかを確認することにしました。 「Nomad」という名前の.Netベースのファイルエクスプローラーがあり、ダウンロードしてテストしましたが、結果はFakeとPowerShellと一致していました。 app_offline.htmファイルを作成しても、プロセスは停止しませんでした。 次に、ファイルの名前を変更し、名前をapp_offline.htmに戻したところ、コアプロセスがシャットダウンしました。

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

このメソッドには、フラグ「FILE_NOTIFY_CHANGE_CREATION」を含める必要があると思います。

Fake、PowerShell、およびNomadに共通の.Net APIが、通常のファイル作成と同じ方法でこれらの他のフラグをトリガーしないのではないかと思います。

@shirhatti誰かがこの潜在的なANCMの問題を調査していることを確認してください。

@davidebboAck 。 私たちはそれを調べています

私は非常によく似た問題を抱えています。 Windowsエクスプローラーでapp_offline.htmファイルをコピーすると、プロセスは正しく停止しますが、ビルドサーバーから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
現在、問題を調査しています。 テストマシンの再現コマンドの1つを使用して、この問題を再現することができました。 以下のコマンドを使用しました。 （注：以下のコマンドは空の（ファイルサイズゼロ）ファイルを作成します。

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"

再現環境で同じ症状が見られるかどうかを確認できますか？
その場合、この問題は、new-itempowershellコマンドを使用するなどの特別な方法で空のapp_offline.htmが作成された場合にのみ発生すると思います。

@gulbanana
コピーコマンドではこの問題を再現できません。 あなたの再現の詳細を説明できますか？ テストマシンで同じ問題を再現できる再現手順を見つけていただければ幸いです。

目的の内容のファイルをデプロイフォルダーにコピーした経験があるため、これらのコマンドを実行せずにapp_offline.htmファイルが空であるかどうかとは関係がないことを確認できます。 私の経験に基づくと、2番目のコマンドが実際に機能している場合は、ファイル変更イベントが発生している可能性があります。 おそらく、ファイルを作成し、その後、内容で更新します。 とにかく、コンテンツの有無にかかわらずファイルを作成するために使用したすべての.net関連のプロセスは、プロセスのシャットダウンをトリガーできません。

@shirhatti更新はありますか？ コードで「FILE_NOTIFY_CHANGE_CREATION」フラグを使用する必要があることを確認できましたか？

@derekgreer最後のアクセスの変更と属性の変更を除くすべての有効なフラグをリッスンしています。
FILE_NOTIFY_VALID_MASK & ~FILE_NOTIFY_CHANGE_LAST_ACCESS & ~FILE_NOTIFY_CHANGE_ATTRIBUTES

そうです、私たちはすでにFILE_NOTIFY_CHANGE_CREATIONをリッスンしています。

cc：@ pan-wang

@shirhattiああ、わかりました。 フラグが変更の作成をカバーしていることに気づいていませんでした。 私は興味があります、あなたは問題を再現することができましたか？

空のapp_offline.htmに反応しないことが修正されたと思われます： https ：//github.com/aspnet/IISIntegration/issues/174

@moozzyk@ derekgreer確認ありがとうございます。 また、この問題は空のファイルの内容に直接関係していないこともわかりました。 根本的な原因を突き止めた後、更新します。

@jhkimnew正確に壊れたセットアップはもうありませんが、詳細を説明できます。

• Windows Server 2008 r2で実行されているIISで、ANCMを使用してasp.netコアアプリケーションをホストしている
• ビルドサーバーも同じドメインの2008r2です
• IISサーバーでは、Windows共有を使用してWebサイトの物理ディレクトリを共有しています
• ドメインユーザー（ビルドサーバーのアカウント）は、ビルドサーバーでPowerShellスクリプトを実行します
  このスクリプトがwindowscopyコマンドを使用して、別のディレクトリにある既存のファイルからapp_offlineをコピーする場合、ホスティングプロセスはシャットダウンしません。 スクリプトが代わりに「echo」（mingwインストールの/ bin / echoである可能性がありますが、よくわかりません）を使用している場合、ホスティングプロセスはシャットダウンします。

問題は、その種類のリモートコピーによって更新されているファイル属性と更新されていないファイル属性に関係しているのではないかと思います。

@gulbanana明確にするために、Power Shellのcopy-itemコマンドレットではなく、dos copyコマンドを試してみましたか？ 通常のdosコピーを試したとは思いませんが、使用した.netベースのアプリは機能しないことがわかりました。

PowerShellにそのエイリアスがない限り、それはDOSコピーでした

私の場合、PowerShellコピーはdotnet.exeプロセスをシャットダウンしませんが、Out-Contentのエイリアスであるechoは機能します。 .NETの問題ではないと思いますが、ネットワークコピーが機能しない理由について詳しく説明します。

aspnetcore.dll（ANCM）の変更通知に問題があるかどうかを調査しましたが、PowerShellコマンドレットまたはDOSコマンドを使用してapp_offline.htmを手動で削除しようとすると、問題を再現できませんでした。 そして、ここで説明されていない1つの欠落点を見つけました。
それは優雅なシャットダウンについてです。 HttpPlatformHandler "とは異なり、ANCMはグレースフルシャットダウンをサポートします。つまり、app_offline.htmがルートディレクトリにドロップされると、ANCMはCrtrl-C / Breakシグナルをバックエンドプロセスに送信し、10秒まで待機してグレースフルシャットダウンが発生します。
10秒がデフォルト値であり、ユーザーはANCM構成設定のshutdownTimeLimitを使用して値を調整できます。 構成されたshutdownTimeLimitでバックエンドプロセスがシャットダウンされていない場合、ANCMはバックエンドプロセスを強制終了することになっています。

MSDeployの公開がANCMの正常なシャットダウンとどのように関連しているかを確認しているときに、シャットダウン時間（5秒）を増やすという一貫した再現手順が1つ見つかりました。また、MSDeployはデフォルトで2回だけ再試行し、2秒しか待機せず、最終的に公開に失敗することに気付きました。正常なシャットダウン時間を待たないためです。

@vijayrkn
aspnetcore Webアプリケーションの開始と終了の両方の場所に5秒の遅延を設定した後、aspnetcore WebアプリケーションをローカルIISサーバーに公開する2回目の試行で、この問題で報告された同じエラーを再現できました。 以下で使用した公開プロファイルも添付しました。
これが発生する理由を説明し、この公開の問題を修正する方法について正しいガイドラインを示しますか？ また、チームがこの問題を追跡してユーザーエクスペリエンスを向上させるために、これについて個別に新しい問題を作成してください。

... <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が1秒の遅延を挟んで10回再試行するようになります。
<RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

@vijayrkn

情報のおかげで。 以下の2行を追加した後、同じ再現環境で問題は発生しません。
<EnableMSDeployAppOffline>True</EnableMSDeployAppOffline> <RetryAttemptsForDeployment>10</RetryAttemptsForDeployment>

したがって、同様の問題が発生した場合は、RetryAttemptsForDeploymentカウントを適切な値で増やし、問題が解決する場合は再試行する必要があります。

注：EnableMSDeployAppOfflineを追加した理由は、ローカルIISサーバーをaspnetcore Webアプリケーションの公開先として使用する場合、デフォルトで無効になっているためです。 したがって、ご使用の環境でそれが有効になっているかどうかわからない場合は、行も追加する必要があります。そのため、ここで情報を追加しました。

最新の議論によって元の問題が失われないようにするために、私のチームが経験した問題は、間違いなくタイミングの問題ではありません。 Powershell、Fake、および「Nomad」という名前の.Netベースのファイルエクスプローラーの両方を使用してapp_offline.htmファイルを手動で作成することをテストしましたが、どれだけ待ってもプロセスはシャットダウンしません。 ファイルエクスプローラー、DOSバッチファイル、またはbashスクリプト（つまり、非.Netライブラリベースのプロセス）を使用してファイルを作成すると、プロセスが1〜2秒以内にシャットダウンします。

これは次のことを示しているようです。

1. 問題はネットワークに関連していません（すべてのテストはリモートファイル共有に対して実行されました）
2. 正常なシャットダウン/タイミングの問題ではありません

app_offline.htmファイルを作成する3つの非.Netメソッドがプロセスを確実かつ迅速にシャットダウンし、ファイルを作成する3つの.Netライブラリベースのメソッドがテストでプロセスをシャットダウンすることは決してないという事実は本当にそうです、私にとって本当に大きな指標です。

@derekgreer
「遊牧民」でも再現できません。
これが私のWindows10（amd64）マシンで行ったことです。

1. IISをインストールします
2. VisualStudio2017をインストールします
3. AspnetCore Webアプリケーションを作成し、MSDeployを使用してローカルIISサーバーに展開します
4. Nomad v3.2.0.2890をインストールします（http://www.nomad-net.info/downloads）
5. Webアプリケーションにリクエストを送信します
6. タスクマネージャーを開き、dotnet.exeプロセスが実行されていることを確認します
7. Nomadを開き、Webアプリケーションのルートディレクトリにapp_offline.htmという名前の新しいファイルを作成します
8. タスクマネージャーを参照し、app_offline.htmファイルが作成されたときにdotnet.exeプロセスがなくなったことを確認します

問題を再現するために私が従うことができるように、正確な再現手順を教えていただけますか？

.NetCoreアプリケーションが実際にはASP.NetCoreアセンブリを参照するVS2015で作成された標準の.Net4.5.2コンソールアプリケーションであるという事実を除けば、違いはわかりません。 プロジェクトは約1年前のものであり、.Netフレームワークテンプレートプロジェクトタイプからコアテンプレートプロジェクトタイプを参照する際の制限と、.Netコアのさまざまな種類のテストライブラリサポートのために、当時はそのように設定されていました。

いくつかの問題を特定しました：1）app_offline.htmファイルを（いくつかのツールを使用して）ドロップすると、ANCMによってフィルターで除外されたファイルプロパティ変更通知のみがトリガーされることがありました。 2）app_offline.htmはファイルコピーツールによって保持されていたため、ANCMはapp_offline.htmの読み取りに失敗する可能性があります。 3）正常なシャットダウンにより、バックエンドプロセスの終了が遅れました。
次のリリースでは、最初の2つの問題に対処します。 正常なシャットダウンの場合、ユーザーは再試行する必要があります。

いいですね。 私の場合は、完全なシャットダウンタイムアウトに関するものではありませんでした。停止すると、すぐに停止します。

この問題に関する更新はありますか？
VSTSを使用してASP.NETCore1.1アプリをAzureWebAppスロットに展開しようとしているときに取得する

• アプリケーション設定でMSDEPLOY_RENAME_LOCKED_FILES=1を設定しています
• アプリサービスの管理タスクは、アプリをオフラインにするように構成されています
• アプリをオフラインにするように設定されたAppServiceタスクをデプロイしますが、それも機能しませんでした

主要な問題は、DLLが使用されていることです。

@ChuckkNorrisの最新情報については、 https： //github.com/Microsoft/vsts-tasks/issues/1607を参照してください。

@davidebbo返信ありがとう、デビッド。 私はそのスレッドを見ました、そしてそれは私が試みた回避策の多くを発見したところです。

この問題はまだ未解決であり、エラーはまだ蔓延しているため、別の回避策ではなく、すぐに修正される可能性があることを期待していました。 結局、この問題は2年以上前から開かれています。

@ChuckkNorris症状は同じですが、これは同じ問題ではありません。

• app_offline.htmのケーシングに関連する元の問題で、完全に無視されます。 それはしばらくの間修正されました。
• この新しい問題は、わずか1週間ほど前に発生しました。これは、 app_offline.htmが作成されたときにCoreのシャットダウンに時間がかかり、デフォルトではmsdeployが十分に長く待機しないために発生します。 回避策は、再試行回数を増やすことです。

VS 2017を15.3に更新し、.NET Core2.0SDKをインストールしました。 VSで単純なMVCアプリを作成しました-それは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.)

@DaveSlinnhttps ://github.com/Azure/app-service-announcements/issues/24を参照してください

2.0アプリをgit経由でデプロイし、ファイルの使用中の問題を防ぐには、MvcViewComplicationを無効にする必要がありました。

https://github.com/Microsoft/vsts-tasks/issues/5259
https://github.com/Microsoft/vsts-tasks/issues/1607#issuecomment -349115532
@davidebbo 、この問題を解決できますか？
Webデプロイ用の再試行ヘルパーを追加したにもかかわらず、この問題は解決していません。

これはFTP公開にも影響するという明らかなことを指摘したかっただけです。

@jeremycook FTPは、App_Offlineを使用するための自動化がないため、少し異なります。 プロセスをシャットダウンするには、そのファイルを手動で作成する必要があります。その後、ファイルをコピーできます。

@davidebboは十分に公平ですが、Visual Studioの公開機能を使用してFTP経由で公開すると、正常に機能するはずです。 おそらく私は間違った場所に投稿していますか？

@jeremycook率直に言って、FTP展開を行うときにVSが何をするのかわかりません。 他の人が輝いているかもしれませんが、ASP.NETというよりはVSの質問のようです。

分離することはできますが、App_Offline.htmlを手動で作成してから、VSからFTP公開する場合に、展開が成功するかどうかをテストすることは興味深いことです。

@vijayrkn FTP展開中のVSの動作についてコメントできますか？

VSからAppサービスへのFTP公開は、App_Offlineをサポートしていません。

@vijayrknわかりました。したがって、すべての実用的な目的で、ユーザーが展開前にサイトを明示的に停止しない限り、FTPを介した.NETCoreの展開はサポートされていないと言えます。 右？

@davidebbo-はい、その通りです。

IISWeb展開テンプレートを使用してVSTSリリースからIISにasp.netコア2.0Webアプリを展開するときにこの問題が発生します。 使用中のファイルが原因で削除に失敗します。 アプリのオフラインオプションが有効になっています。

@davidebbo @ vijayrkn@ shirhattiこれは少し気のめいるようです。 FTP / XCOPYを機能させる計画はありますか？ FTP / XCOPY / ROBOCOPYなどを介した昔ながらの方法の展開に焦点を当てた新しい問題を開く必要がありますか？

私はこのパーティーに遅れていますが、ここに私が報告したいいくつかのビットがあります：
VS2017エンタープライズ
asp.net 4.6.xx
サーバーはサーバー2012R2上のIIS8.5です
sqlサーバータイプのdllはロックされており、別の開発者がmsdeployを使用して公開するとエラーが発生し、デプロイの一部のみが実行されたためにWebサイトが壊れます。

SQLタイプのdllは、アプリのbinフォルダーにロックされており、それらのみがロックされています。
dllファイルの名前を変更すると、公開できます。
SQLタイプのパッケージには、アンマネージdllをロードするためのコードが含まれています。
それらをロックしないように変更する必要があるようです。 それができるなら。

サイトを再起動したりオフラインにしたりする方法について話している人を見かけましたが、msdeployに設定が見つかりませんでした。 私が見たxmlは私のファイルにありません。

マイクロソフトが公開しているSQLタイプパッケージに、より適切なガイダンスを追加する必要があります。

この問題は私のものに直接関係しているように思われるので、投稿してください。 VSTS用ですが、同じトピックについて以下の問題もフォローしました。 VisualStudioから直接公開しています。

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

これは私にとってオンとオフの問題でしたが、最近有効になり、私のアプリサービスサイトの1つで、ほとんどすべての公開試行でこのエラーが発生します。 このサイトは「基本」レベルのサービスでホストされているため、この問題を回避するために他のアプリで使用するスロットはありません。

これは、.netコア2MVCアプリケーション用です。

1つの考え：Webアプリの一部である一部のファイルは、すべての公開で変更されません（SQLタイプなど）
しかし、ms deployは、すべてのデプロイでそれらを置き換えようとしています。
変更されていないファイルを再コピーしないように、ある種のチェックが行われるべきであるように思われます。これにより、更新がより小さく、より速くなり、ファイルロックを台無しにする必要が少なくなります。
それが可能であれば、複数のメリットがあります。

もう1つは、ファイルをロックしている原因と、それを元に戻す理由と方法をより適切に特定することです。
標準のデプロイメントパイプラインの一部としてそれを取得します。

@figuerres私はこの問題に数ヶ月間対処したいと思っていました。 通常、シャドウコピーによりロックの問題は回避されますが、これらのネイティブDLLを~/binからロードすることにより、ロックの問題が発生します。 私は潜在的な解決策を持っていますが、それが完全に安全な解決策であるかどうかはわかりません： https ://stackoverflow.com/questions/47796553/is-it-safe-to-manually-copy-native-dlls-to-

NuGetパッケージのドキュメントが、ロックの問題を引き起こさない、より優れた方法を提供する必要があることに同意します。

@figuerres参考までに、上記を実装しました。コードについては、StackOverflowの質問を参照してください。

タスクマネージャーでdotnet.exeを強制終了します

ここのステータスはどうですか？ 3年経ちましたが、まだ修正されていません。 手動でサーバーにアクセスしてWebサイトを停止する必要があります。

3年？ この問題は2017年8月に報告されました。
2018年4月23日月曜日午後8時56分[email protected]
書きました：

ここのステータスはどうですか？ 3年経ちましたが、まだ修正されていません。 私は手動で行かなければなりません
サーバーに移動し、Webサイトを停止します。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/Home/issues/694#issuecomment-383768450 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAXhfrhOTvZn2qb4kU-Y1Kg9I-IQKD9yks5trnhXgaJpZM4FJp_R
。

最初の投稿には、「ペッカは2015年6月23日にこの号を開いた」と書かれています。

あなたが正しい。 私のせい。 メールチェーンの最後のタイムスタンプしか表示されませんでした。
2018年4月23日月曜日午後9時6分[email protected]
書きました：

最初の投稿には、「ペッカが2015年6月23日にコメントした」と書かれています。

—
コメントしたのでこれを受け取っています。

このメールに直接返信し、GitHubで表示してください
https://github.com/aspnet/Home/issues/694#issuecomment-383769982 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AAXhfgwYG-jLjnoJF7MCMtzbbfxSZkt2ks5trnqXgaJpZM4FJp_R
。

これは汚れと同じくらい古いので閉じます😄

@Eilon申し訳ありませんが、なぜこれが閉鎖されたのですか？ それはまだ解決されていませんか？

これは汚れと同じくらい古いので閉じます😄

しかし、それはまだ問題です..？ （なし-azureデプロイでも）

可視性を高めるために新しい問題（＃3719）を作成しました。