Aspnetcore: IIS-> .NETCoreアプリケーションDLLファイルをロックする

app_offline.htmを参照してください： https ：//docs.asp.net/en/latest/hosting/aspnet-core-module.html#asp -net-core-module-app-offline-htm

PowerShellの方法が必要な場合は、IIS管理コマンドレットを使用できます： https ：

Stop-WebAppPool -Name $appPoolName

... deploy ...

Start-WebAppPool -Name $appPoolName

説明をありがとう@Tratcher 。
これがあなたの計画にあるかどうかはわかりませんが、これは以前のASP.NET MVCで機能したと思いますか？
この機能を実装する予定はありますか？

@GuardRex共有ホスティング環境であり、AppPoolを停止する権限がないため、実行できません

msdeploy.exeとAzureで「正しく機能する」ようにできますか？ 私が正しく理解している場合は、ファイルロックを防ぐためにWebサイトを再起動する必要があります。 -enableRule:AppOffline機能しますが、Webサイト全体が数分間オフラインになります。これは、特に1日に数回展開することを考えると、優れたユーザーエクスペリエンスではありません。

http://stackoverflow.com/q/40276582/14131も参照して

@chuchuvaかもしれませんが、すべての魔法にはコストが伴います。 以前のバージョンのASP.NETは、ファイルロックの問題を回避するために、いくつかの複雑なシャドウコピーを実行していました。

魔法かどうか、それはうまくいきました。 ASP.NETコアへの移行後、今はちょっと懐かしいです...

@HarelMに同意しました。 自動展開からエンドユーザーエクスペリエンスまで、これに関する問題が発生しました。 古いMVCを使用した1日約10回のデプロイから、おそらく夜間の毎日のデプロイに移行し、Coreアプリを使用しているユーザーがオフラインにするとイライラすることを受け入れました。 ショーストッパーではありませんが、コアの採用に向けて摩擦が加わります。

👍

重複したリサイクルをサポートしないことは回帰です。

この機能を再検討してロードマップに載せる予定はありますか？ ダウンタイムゼロの展開をサポートしたい場合、.Net Core Webサイトを展開するすべての人に、ステージングスロット戦略を手動で実装するように要求することは非常に不便で不便です。

この機能を使用すると、多くの人にとって.Net Core Webサイトへの移行がはるかにスムーズになり、.Net CoreWebサイトをより迅速に採用できるようになります。

私たちも知りたいです。 app_offline.htmをapplicationsディレクトリ内に配置しても機能しません。

多くのサイトをAspNetCoreに移行した後、この「機能」に気付いたばかりです。 公開するたびにサイトを数分間オフラインにすることは許容できるとは思えません。

これは、小さなチームのリーダーとしての私にとっては十分に悪いことです-大規模な回避的AspNetCoreで継続的インテグレーションを実践している人はいますか？ 再公開するために、1時間ごとに数分間サイトをオフラインにする方法はありません。

FTPまたはxcopyingを使用して展開していますか？ または、webdeployを使用していますか？

webdeployを介してIISに公開しています。

現在、最初にweb.configを削除する（事実上アプリケーションを強制終了する）ことでこの問題を回避していますが、これは長期的には実際には受け入れられる解決策ではありません。

@DaleMckeownは、理想的には継続的インテグレーションワークフローを使用して、ロードバランサーの背後に複数のサーバーを配置します。 次に、1つのサーバーをプルして更新し、元に戻して次のサーバーに移動します。 もちろん、これが常に可能であるとは限らないため（私たちの場合のように）、数分のダウンタイムで生活する必要があります。 私たちの場合、アプリは30秒以内にバックアップされるため、これは実際には問題ではありません。

@DaleMckeown

webdeployを介してIISに公開しています。

webdeployを使用したデプロイメントを適切に機能させるために使用できるオプションがいくつかあります（ロックされたファイルの名前の変更とアプリのオフラインの自動ドロップをサポートします）。 それはデフォルトで@shirhattiの場合ですか？

@ajeckmans

現在、最初にweb.configを削除する（事実上アプリケーションを強制終了する）ことでこの問題を回避していますが、これは長期的には実際には受け入れられる解決策ではありません。

これは、xcopy展開を行っていることを意味しますか？

webdeployを使用したデプロイメントを適切に機能させるために使用できるオプションがいくつかあります（ロックされたファイルの名前の変更とアプリのオフラインの自動ドロップをサポートします）。 それはデフォルトで@shirhattiの場合ですか？

Davidに感謝します-私が現在行っていることよりも良い音がします（IISのサイトとアプリプールを手動で停止します）。 これらのアプローチの影響を調査できるように、いくつかのリソースを指摘できますか？

@DaleMckeown信頼できる情報源が見つかるまで、 https： //github.com/Microsoft/vsts-tasks/issues/5259#issuecomment -346202503

@davidfowl webdeployを使用してテストサーバーにデプロイしています（ところで問題が発生することはありません）。そこから、robocopyを使用してファイルをライブサーバーにコピーします。

@ajeckmans

現在、最初にweb.configを削除するだけで、この問題を回避しています。

web.configが展開から削除されると、IISは展開から機密ファイルを提供します。 攻撃者は、30代のウィンドウが開くまで、昼夜を問わずファイルを継続的に要求する可能性があります。

@DaleMckeown

@ajeckmansのアドバイスに従って、PSアプローチで少し雑草を調べたい場合は、Webファーム全体に展開するためにAppPoolsを一度に1つずつドロップするプロセスをスクリプト化できます。 これを行う方法の例については、 https：//github.com/guardrex/aspnetcore-iis-ps-publish ...を参照して

@guardrexその通りです。 最初にapp_offline.htmをdirにコピーしてから、web.configを削除し、アプリケーションをコピーして、web.configを元に戻し、app_offlineを削除します（すべてスクリプトofcを使用）。 残念ながら、app_offlineファイルをwebsitesディレクトリに配置するだけでは、dllのロックは解除されません。 web.configを削除する必要があります。これは、古いasp.netフルアプリ（古いWebフォームなど）では実行する必要のないアクションです。

@ajeckmansそれはうまくいかないはずです。 web.configファイルが削除されると、IISはその変更をすぐに取得するため、デフォルトで静的ファイルモジュールに要求を渡し、ファイルの提供を開始する必要があります。 それを試して、それが起こるかどうかを確認してください...

1. app_offline.htmを追加し
2. サイトがapp_offline.htmを提供していることを確認します。
3. web.configを引き出します。
4. 機密ファイルを要求します（たとえば、 http://localhost:<PORT>/<ASSEMBLY_NAME>.deps.json ... PORTとASSEMBLY_NAMEを置き換えます）。
5. 静的ファイルモジュールが正しく機能している場合は、 deps.jsonファイルを提供する必要があります。

モジュールを削除するだけでは信用できません...

<configuration> 
 <system.webServer> 
   <modules> 
     <remove name="StaticFileModule" /> 
   </modules> 
 </system.webServer> 
</configuration>

...他のモジュールが残り、他の攻撃ベクトルを提示する可能性があるため。 必須ではないモジュールをすべて削除できるかもしれませんが、 web.configの削除によるデプロイメントをカバーするためだけに、そのような動きで未知の海に突入しています。 これは公式ガイダンスではオプションではなかったため、完全にサポートされていません。 たとえば、AppPoolを停止するためのPSスクリプト、またはその他の戦略をお勧めします。

私はそれに同情のメモを追加する必要があると思います...それはセキュリティの観点からいくつかの眉を上げました。 そのデプロイメントレイアウトの変更が行われたとき、ファイルをwwwrootに戻すことを含め、それが議論されました。...を参照してください。

ディスカッション：IISの変更をweb.configの場所に公開する（IISIntegration 158）
web.configをwwwroot戻す際のヘッドチェック（IISIntegration 164）

[編集]おそらくそれがあなたの（サポートされていない）回避策です： web.configをwwwrootに戻し、次にurの実行を続行します。 それでも...アプリを壊してそのようにオフラインにするのは怖いです。

これは、私たちがこの状況で何をすべきかについてさらに混乱させます。

ファイルロックを回避できる方法でWeb展開を介してAspNetCoreサイトをIISに公開するための現在の推奨事項は何ですか？

私も知りたいです。 これは、私の組織で.netCoreを採用する際の大きな障害になりつつあります。

.netコアWebアプリケーションが実行されていて、新しいビルドを公開しようとすると、DLLが使用されているというエラーが表示されます。 そのため、アプリプールを停止してから、DLLを更新し、アプリプールを起動する必要があります。

アプリプールを停止せずに新しいビルド/ DLLを公開できる回避策は.NetCoreにありますか？

これは、シャドウコピーメカニズムを使用する.Netフレームワークでデフォルトでサポートされています。 残念ながら、.Net Coreのリリースから2年が経過しており、このような非常に基本的で必要な機能はまだサポートされていないようです。 将来これを修正する計画さえありますか？

助けてくれてありがとう。

@guardrexアプリを壊してIIS（またはロックを保持しているもの）を取得してdllを解放するのは確かに怖いですが、修正プログラムを製品にプッシュできないのはさらに怖いです。 当分の間、アプリを壊すことが私たちにできる唯一のことですが、私たちはこれを処理するための他のより現代的なアプローチを頻繁に検討しています:)

@ shahjay748息を止めないでください。 ここでプロセスをやり直した場合は、アプリをコンテナー内に配置し、新しいコンテナーを配置してトラフィックを切り替え、古いバージョン（またはそのようなもの）をプルダウンします。 .net Coreは新しい最新の方法がすべてであるため、より正気なことのように思われます。新しいファイルをコピーするだけでアプリの新しいバージョンをプッシュすることは、少し難解な方法と見なされます（同意します）。それを行うには。
とりあえず、古いプロセスで立ち往生している私たちを助けないのはどれですか:)

私がしていること（それが適切な方法かどうかはわかりません）は、サイトを別のディレクトリにアップロードし、iisのパスを切り替えることです

この問題について内部調査を行いました。 私の知る限り、ANCMはデプロイされたアプリケーションにファイル/ハンドルを保持していません。 これはwebdeploy自体に問題があるようで、デプロイに失敗します。 app_offlineが削除された後、数回再試行した後、アプリケーションのデプロイに一貫して失敗することはありませんでした。

これにPowerShellの簡単な補足事項を追加します。アプリのアセンブリのロックは常に解放されます...問題が発生したことはありません（

@ bpetersen1 ...「ステージング」アプローチには、新しい展開が

これはまだ外部的に迷惑です... IISを残すためにDockerソリューションを検討することにしました。

解決策を試してみます。 乞うご期待。

FTPを使用してもこの問題が発生しています。

これに関するマイクロソフトのアドバイスは何ですか？！

FTPを使用してもこの問題が発生しています。

これに関するマイクロソフトのアドバイスは何ですか？！

appoffline.htmファイルをドロップし、次にftpで削除します。

@davidfowlはい、それは私が現在バッチファイルで行っていることです。 IISがロックを解除してから、ファイルをコピーするのに数秒かかります。

ありがとう-興味がないので、バッチファイルをどのように実行していますか？

また、これに関するMIcrosoftのドキュメントへのリンクもありがたいです。 グーグルで見つけられません。 ありがとう。

@ niico100基本的に、バッチファイルはファイルをプロジェクトディレクトリにコピーするだけで、それを行う前にまずバックアップフォルダを作成します。 ファイルをコピーする前に、appoffline.htmをプロジェクトフォルダーに配置します。
ファイルロックの問題が発生すると、コピーが再試行されます。 私はrobcopyを使用しています
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy

興味がある場合は、次のスクリプトがappveyorからデプロイメントファイルをダウンロードし、サイトを停止し、必要なファイルをコピーして、サイトをバックアップします。
https://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deploy.ps1
ただし、管理者として実行する必要があります。 うまくいけば、dockerは移行したらこのナンセンスをすべて解決するでしょう...
Stop-WebAppPoolおよびStart-WebAppPool PowerShellコマンドを使用します。

ローカル開発の場合、WebDeployは機能しませんでした。 ローカルIISに対して使用しようとしましたが、ファイルがロックされていると文句を言います。 次に、VS Pre / Postビルドイベントから上記のPowerShellコマンドレットを使用してみましたが、おそらく32ビットのPowerShellが64ビットのIIS設定を変更できないため、それも機能しませんでしたか？ とにかく、うまく機能しているように見えるのは、ASP.NetCoreプロジェクトの次のビルド前後のイベントです。

ビルド前のイベント：
echo "App Offline" /a > $(ProjectDir)app_offline.htm

ビルド後のイベント：
del $(ProjectDir)app_offline.htm

私はここで不平を簡単に熟読しました、そしてこれは関連しているようです。 CIデプロイメントを、一般的に「機能した」タコのデプロイから、iis管理タスクでazure devopsリリースを使用するように移動しましたが、webappを停止した後、アプリドメインを停止した後でも、ファイルがまだ残っているため、新しいファイルのデプロイで問題が発生することがよくあります。使用する。

これはおそらく、デプロイの3分の1に少なくとも1つあり、状況を改善したり、デプロイの信頼性を高めたりするようなものは何も見つかりませんでした。

@ Tratcher @ ronnyekこれはApplicationInsightsに関連しているようです。 App Insights拡張機能を追加した後、私のWebアプリDLLを突然更新するのが非常に難しくなり、それまでは問題はありませんでした。

App InsightsがプロファイラーをアプリプロセスとDLLに接続する必要があることを考えると、これは理にかなっています。

私はまだこの問題に直面しています。 フラグ-enableRule：AppOfflineを使用します

リリースを開始した後、Webアプリケーションフォルダーを監視し、msdeployによってドロップされたApp_Offline.htmlを確認します。 次に、上記のメッセージでリリースが失敗し、App_Offlineファイルがまだフォルダーにあることに注意してください。リリースを再開します。今回は、モジュールがフォルダー内のファイルを確認できるため、正常に機能しています。

最後にインストールされたasp.netコアランタイム-> aspnetcore.dll 12.1.18263.2

何か案は ？ まだバグ？

@dhtek app_offline.htm配置した直後にファイルを置き換えようとすると、サーバーにはアプリケーションをシャットダウンするのに十分な時間がありませんでした。 ファイルの置き換えを試みる前に、少し待つ必要があります。

わかりましたが、 msdeployの-e

私もまだこの問題を抱えています。 私のプロジェクトファイルはMicrosoft.NET.Sdk.Web参照していますが、ドキュメントに記載されているように、 app_offline.htmファイルを自動的に削除していません。

こんにちは、みんな。 この厄介な問題は、最新のVS2017を搭載したCore2.1でも引き続き発生します。appofflineを使用していますが、メインプロジェクトのdllは常に使用されており、公開中にWebサイトを完全に停止する必要があります。 これにより、Webデプロイはほとんど役に立たなくなります。

ロードバランサーの背後でホストをオフラインにすることができず、より迅速に実行したい場合は、シンボリックリンクといくつかのPowerShellを使用する1つの方法があります。
こんなことを考えていました。

コピー+リサイクル中にアプリプールを停止する必要がないため、現在のリクエストを完了できるため、ダウンタイムが少なくなるため、ハードストップよりも高速です。

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

ここに要点があります
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

再起動-WebAppPoolは基本的にリサイクルです。これは、重複したリサイクルを有効にしている場合（デフォルト）に便利です。新しいw3wp.exeが生成され、現在実行中のリクエストが完了するまで、すべての新しいリクエストがその新しいプロセスによって処理されます。古いw3wp.exeによって。
このように、古いリクエストが完了するまでそれらは重複し、新しいバージョンを指す単一のw3wp.exeが作成され、ロックの問題は発生しません。

これはシャドウコピーに似ていますが、100％ではなく、はるかに優れたシームレスなxcopyシナリオを提供します。

これまでのところ、リリース中にオンラインを維持する必要がある場合は、私が考えることができる最善のアプローチのようです。

@csharmathまたは私が推測する

もちろん、それはさらに良いことです。 ため息、まだすべての場所にそれがあるわけではありません。
残りのオールドスクールのセットアップでは、ダウンタイムが発生しないか最小限に抑えられるまで、それをyakshaveする必要があります。

@csharmath同意しましたが、現時点では、これが_years_の未修正の問題であったことを考えると、奇跡を待つのではなく、うまく機能する解決策を採用して追求することもできます...

以下のPowerShellスクリプトを使用しましたが、IISがクラッシュし、他のアプリケーションプールにも影響があり、すべてを元に戻すにはマシンを再起動する必要があります...このプロセスは公式ドキュメントから取得したもので、災害でした。私のアドバイスは、このスレッドhttps://github.com/IsraelHikingMap/Site/blob/master/Scripts/Deployで見つけた、アプリプールを停止して再開するスクリプトを使用するためにapp_offline.htmを使用しないことです

$pathToApp = 'G:\prod_web_core'
$pathToAppOfflineHtml = 'G:\prod_web_core\app_offline.htm'
# Stop the AppPool 
New-Item -Path $pathToApp -Name app_offline.htm
# Provide script commands here to deploy the app
Copy-Item "G:\prod_web_core_temp\*" -Destination $pathToApp -Recurse -Force
# Restart the AppPool 
Remove-Item -Path $pathToAppOfflineHtml
Get-ChildItem -Path "G:\prod_web_core_temp" -Recurse | Remove-Item -Force

デプロイを成功させるためにAppPoolを強制的に停止しますが、この問題を修正するための進捗状況はありますか？！

dotnet coreは私たちにとって新しいので、今日初めてこのファイルロックの問題に遭遇しました。 私はこれに本当に気を失いました。 まだベータ版（〜2001）のときにClassicASPから.NetFrameworkに切り替えた最大の理由は、ファイルをロックせずにホットデプロイメントを実行できたためです。 それはすごかった！ ほぼ18年後、今、私は始めたところに戻っています。 まあ、あなたはいくつかを勝ち取り、いくつかを失います。

私は自分の問題を参照しました...私の場合はBlazorサーバーサイドソリューションを展開しています...
数日前は悪夢でした... app_offline.htmを適用し、アプリプールをシャットダウンし、IISインスタンス全体を再起動してファイルのロックを解除しました。 次のステップは、サーバー全体を再起動することでした。幸い、5分後に.dllがロック解除されました。

2019、私にとって同じ問題...そしてこの問題は2016年に作成されました...まだ解決策はありませんか？

2020年、私にとっても同じ問題。 史上最大の回帰。 .Net 4.6 dllファイルを置き換えると、アプリは新しいバージョンでリロードされます。 .NetCoreはすべてをロックします。

@bladefist今日の最善の策は、Dockerコンテナを使用することです：/

@kanadajに感謝しますが、Dockersは対処すべき頭痛の種のもう1つの層です。 最終的に、App_offline.htmを使用して、1分待ってから、ファイルが無料になることを期待する回避策を見つけました。 99％の確率で、待つ必要があります。私のアプリの電源が切れるまでしばらく時間がかかると思います。

.net 4.6の時代は終わり、dllをコピーして、アプリを自動リサイクルしました。 単純すぎたと思います。 二重に苛立たしいのは、これがLinuxの問題ではないということです。 Linuxで使用中のファイルを置き換えることができます。

そうですね、私は推測しますが、その方法は実稼働環境ではそれほど単純ではありません。 HAがないと、アプリは1分間応答しなくなり、HAを使用すると、ロードバランサーがアプリがダウンしていると判断するまで、ランダムに不正なリクエストが発生します...ロードバランサーでホストを手動で循環させない限り。 しかし、それはセットアップがさらに面倒なように思えます。

@kanadajうん、ロードバランサーを使用すると、サーバーが線形に更新されます。 ダウンタイムはありません。

私たちは成功しました

• アプリディレクトリのシンボリックリンクの使用
• 新しいバージョンのサイトを別のディレクトリに展開します
• シンボリックリンクを更新する
• IISに付属のappcmdユーティリティを使用してアプリプールを再起動します。

@davidglassborowそれは創造的な解決策です。 ありがとう。 ただし、クリエイティブなソリューションは必要ありません。

私の経験では、サイトに負荷がかかっているときは古いメカニズムの信頼性が低く、トラフィックの多いサイトにはとにかくリバースプロキシを配置することになりました。

確かに、インプレース展開は信頼性が高く、アトミックではありませんでしたが、運が良かった場合やトラフィックが少なかった場合は問題ありません。 苦情の大部分はそれらのシナリオに関連していると思います。 .NET5.0の時間枠で物事を改善することを検討します。 いくつかの警告：

• フレームワークに依存するアプリケーションのために物事をより良くすることを検討します。 自己完結型を展開する場合は、運が悪いです。 出力フォルダー内のネイティブファイルと管理対象ファイルの両方をロックします。 ネイティブdllのロックの問題は常に存在しており、どのような緩和策を講じても修正されません。
• アプリケーションアセンブリをディスクからロードしてファイルをロックするのではなく、バイトとしてメモリにロードすることを検討する予定です。 これはほとんどの場合問題ないはずですが、場合によってはメモリ使用量が増える可能性があります。
• アプリケーションをリサイクルするには、appofflineファイルを追加および削除する必要があります。 appofflineファイルを追加することは、デプロイメントの結果としてアプリケーションを再起動することを通知する方法です。

@ davidfowl5.0について概説した計画は素晴らしいですね。 ほとんどの場合、フレームワークに依存するものを使用します。

インプレース展開の信頼性については、敬意を表して意見が分かれています。 私は非常に負荷の高いサイトで何年もそれを行ってきましたが、一度も問題はありませんでした。 最初に検出された変更によりアプリがリセットされ、ロードバランサーはインスタンスが応答していないことを確認してオフラインにします。すべてのDLLが置き換えられると、ロードバランサーはヘルスチェックを完了してオンラインに戻ります。 ロードバランサーのヘルスチェックがなかった場合、それはギャンブルですが、ある種のプロキシを使用して高負荷で本番環境のDLLを置き換えるのは誰ですか？ 例外ではなく、ルールに焦点を当てましょう。 プロキシがないと、停止を引き起こさずにアプリを更新する方法は考えられません。 ホットリロードをサポートしている場合でも、一部のリクエストはハングまたは失敗する可能性があります。

インプレース展開の信頼性については、敬意を表して意見が分かれています。 私は非常に負荷の高いサイトで何年もそれを行ってきましたが、一度も問題はありませんでした。 最初に検出された変更によりアプリがリセットされ、ロードバランサーはインスタンスが応答していないことを確認してオフラインにします。すべてのDLLが置き換えられると、ロードバランサーはヘルスチェックを完了してオンラインに戻ります。 ロードバランサーのヘルスチェックがなかった場合、それはギャンブルですが、ある種のプロキシを使用して高負荷で本番環境のDLLを置き換えるのは誰ですか？ 例外ではなく、ルールに焦点を当てましょう。 プロキシがないと、停止を引き起こさずにアプリを更新する方法は考えられません。 ホットリロードをサポートしている場合でも、一部のリクエストはハングまたは失敗する可能性があります。

ロードバランサーがあります。 多くの人はロードバランサーを持っておらず、ディスク上のファイルを所定の場所で置き換えており、魔法を期待しています😄

@davidfowl正しいが、トラフィックが多い+ポンドなし=無謀

また、app_offline.htmの問題は、ci / cdプロセスから、プロセスがいつ停止するかわからないことです。 シャットダウンプロセスには1秒から1分かかる可能性があるため、そのファイルの作成とDLLのプッシュの間に巨大なスリープコマンドを追加する必要がありました。 大量のインスタンスを負荷分散している場合、それらのスリープは非常に長いデプロイサイクルになります。

ただし、ファイルをメモリにロードすると、すべて修正されます。

@davidfowl正しいが、トラフィックが多い+ポンドなし=無謀

👍

また、app_offline.htmの問題は、ci / cdプロセスから、プロセスがいつ停止するかわからないことです。 シャットダウンプロセスには1秒から1分かかる可能性があるため、そのファイルの作成とDLLのプッシュの間に巨大なスリープコマンドを追加する必要がありました。 大量のインスタンスを負荷分散している場合、それらのスリープは非常に長いデプロイサイクルになります。

そうです、問題は、そのファイルを削除しても、ANCMが通知を受信するまでファイルがロックされたままであるため、展開を開始してもよいかどうかがわからないことです。

また、app_offline.htmの問題は、ci / cdプロセスから、プロセスがいつ停止するかわからないことです。

そうです、VSパブリッシャーは短いスリープと数回の再試行を使用します。

• アプリケーションをリサイクルするには、appofflineファイルを追加および削除する必要があります。 appofflineファイルを追加することは、デプロイメントの結果としてアプリケーションを再起動することを通知する方法です。

後でappofflineファイルを削除せずに、アプリをリサイクルするようにマークする「apprestart」ファイルを作成することは可能でしょうか。

@Socolinそれはなぜですか？

@Socolinそれはなぜですか？

私がよく理解している場合（間違っている場合は教えてください）、ロックを解除する予定ですが、ビルドの完了後にアプリをリサイクルするようにIISに通知するappofflineを作成する必要がありますか？

これを行うには、ファイルappofflineを作成してから、削除する必要があります。 このファイルは、ファイルが作成された直後に削除できますか？ または、IISがそれを検出するのを待つ必要がありますか？ 少し待つ必要がある場合は、IISがリッスンする「apprestart」のようなファイルを用意し、それを検出したら削除してリサイクルを開始します。

また、別の質問もあります。 ビルド中のIDEの最適化についてです。

現在、私は依存関係を使用するプロジェクトに取り組んでいます。Webレイヤー用のプロジェクトと、ロジックとデータ用の他のプロジェクトがあります。 ビルド中にWebレイヤー（ASP.NET Core）で作業する場合、ビルド前にappofflineファイルを作成し、ビルド後に削除すると機能します。

しかし、依存関係の1つで作業するとき、Riderからビルドするとき（msbuildを使用しているのでVSでも同じことをしていると思います）、msbuildが何をしているのかを見ると、プロジェクトのビルドが完了すると、 dllは、.Webプロジェクトを再構築せずに、.Web / binディレクトリに直接コピーされます。 また、dllがロックされているため、サイレントに失敗し、サーバーを手動で再起動するか、.Webプロジェクトのビルドを手動でトリガーする必要があります。

これに対する解決策はありますか？
これまでのところ、私が見つけた回避策は、バックグラウンドで実行されている小さなプログラムを作成して、.Webプロジェクトの/ binを探すことです。 ファイルが変更されると、IISがリッスンするディレクトリにappofflineファイルが作成され、変更されたファイルがコピーされてから、appofflineが削除されます。 しかし、少しハッキーな感じがしますが、これまでのところ、ビルドできることがわかった唯一の方法です。次にF5キーを押して、変更をテストします。

これを行うには、ファイルappofflineを作成してから、削除する必要があります。 このファイルは、ファイルが作成された直後に削除できますか？ または、IISがそれを検出するのを待つ必要がありますか？ 少し待つ必要がある場合は、IISがリッスンする「apprestart」のようなファイルを用意し、それを検出したら削除してリサイクルを開始します。

ファイルのコピーが完了したことをIISはどのように知るのでしょうか。 引き裂かれた状態をどのように回避しますか？ 基本的に、トランザクションの開始と完了を通知する必要があります。 ファイルの作成は開始を示し、削除は終了を示します。

これに対する解決策はありますか？
これまでのところ、私が見つけた回避策は、バックグラウンドで実行されている小さなプログラムを作成して、.Webプロジェクトの/ binを探すことです。 ファイルが変更されると、IISがリッスンするディレクトリにappofflineファイルが作成され、変更されたファイルがコピーされてから、appofflineが削除されます。 しかし、少しハッキーな感じがしますが、これまでのところ、ビルドできることがわかった唯一の方法です。次にF5キーを押して、変更をテストします。

VSは、そのプロジェクトの構築に影響を与える可能性のあるものについて、新しいファイルを開始する前にプロセスを強制終了することでこれを処理します。

これを行うには、ファイルappofflineを作成してから、削除する必要があります。 このファイルは、ファイルが作成された直後に削除できますか？ または、IISがそれを検出するのを待つ必要がありますか？ 少し待つ必要がある場合は、IISがリッスンする「apprestart」のようなファイルを用意し、それを検出したら削除してリサイクルを開始します。

ファイルのコピーが完了したことをIISはどのように知るのでしょうか。 引き裂かれた状態をどのように回避しますか？ 基本的に、トランザクションの開始と完了を通知する必要があります。 ファイルの作成は開始を示し、削除は終了を示します。

ロックがない場合、ビルドの開始時にIISに通知するのはなぜですか？ すべてのファイルが更新され、アプリケーションをリサイクルする必要がある場合に通知することはできませんか？ 私は何かを誤解したと思います。

ロックがない場合、ビルドの開始時にIISに通知するのはなぜですか？ すべてのファイルが更新され、アプリケーションをリサイクルする必要がある場合に通知することはできませんか？ 私は何かを誤解したと思います。

はい、それはうまくいくでしょう。 あなたは現在の最先端技術を説明していると思いました。 今日、web.configを使用してこれを行うことさえ可能かもしれません。 ファイルに触れると、アプリケーションが再起動します。

インプレース展開（https://flukefan.github.io/ZipDeploy/）で成功しました。

1. アセンブリファイルの名前を変更します（削除/上書きできない場合でも、明らかに名前を変更できます）。
2. 新しいアセンブリをコピーします。
3. web-configをタッチして、アプリを再起動します。
4. 名前が変更された古いアセンブリを削除します。

負荷分散なし。 単一のIISインスタンス。 IISの変更はありません。 YMMV。

@FlukeFan展開の

すべてのアセンブリの名前が変更/更新されるまで、web.configには触れません。 その間に何か他のものがアプリプールをリサイクルする可能性はわずかにあると思いますが、それはまだ起こっていません。

私は通常、他のすべての自動リサイクルオプションをオフにし、IISアプリプール設定で重複リサイクルも無効にします。

@FlukeFanはリサイクルではありませんが、交換されたアセンブリをまだロードしていない場合。 たとえば、アセンブリA.dllとB.dllがあるとします。 設定ページに移動するとBが使用されるので、ロードされたとします。 B.dllが新しいものに置き換えられたときに設定ページに移動すると、古いアプリが新しいB.dllで実行される可能性があります。

このタイプの展開を支援するために、dotnetグローバルツールを作成する必要があるのではないかと思います。 このツールは基本的に、このスレッドで人々が言及したすべての難しいことを実行できます。

考え？

@FlukeFanはリサイクルではありませんが、交換されたアセンブリをまだロードしていない場合。 たとえば、アセンブリA.dllとB.dllがあるとします。 設定ページに移動するとBが使用されるので、ロードされたとします。 B.dllが新しいものに置き換えられたときに設定ページに移動すると、古いアプリが新しいB.dllで実行される可能性があります。

だから私は今そのケースを処理していません。 https://github.com/FlukeFan/ZipDeploy/blob/master/ZipDeploy/ZipDeploy.cs#L55

私は別の順序で物事を行うことができると思います。最初にweb.configにタッチし、すべての「その他」のリクエストが終了するのを待ってから、最後のリクエストが終了する直前に最後に置換を実行します（IISが新しいリクエストをキューに入れている間） recycle app-pool）ですが、私が持っているものは今私のために働いています。

おそらく現在、あなたが説明しているシナリオに対して十分に堅牢ではありません（ただし、起動時以外は、動的なアセンブリの読み込みについては何もしていません）。

この機能を再検討してロードマップに載せる予定はありますか？ ダウンタイムゼロの展開をサポートしたい場合、.Net Core Webサイトを展開するすべての人に、ステージングスロット戦略を手動で実装するように要求することは非常に不便で不便です。

この機能を使用すると、多くの人にとって.Net Core Webサイトへの移行がはるかにスムーズになり、.Net CoreWebサイトをより迅速に採用できるようになります。

私はそれを考えたことはありません。 しかし、あなたは頭に釘を打った可能性があります。 これは、人々に紺碧のスロットを使用させるという悪質なビジネス上の決定である可能性があります。 過去に可能だったとしたら、なぜ今「修正」するのにそれほど時間がかかったのでしょうか。 それが何を念頭に置いているかは、ビジネスの観点からは壊れていません。 多分私は少し皮肉です。 しかし、以前は無料で削り取られ、より高価な層に移動していた紺碧の機能をゆっくりと見てきました。

このタイプの展開を支援するために、dotnetグローバルツールを作成する必要があるのではないかと思います。 このツールは基本的に、このスレッドで人々が言及したすべての難しいことを実行できます。

考え？

これはCIサーバーで実行することです。 バイナリ/パッケージを宛先サーバーにどのようにプッシュしますか？

私はそれを考えたことはありません。 しかし、あなたは頭に釘を打った可能性があります。 これは、人々に紺碧のスロットを使用させるという悪質なビジネス上の決定である可能性があります。 過去に可能だったとしたら、なぜ今「修正」するのにそれほど時間がかかったのでしょうか。 それが何を念頭に置いているかは、ビジネスの観点からは壊れていません。 多分私は少し皮肉です。 しかし、以前は無料で削り取られ、より高価な層に移動していた紺碧の機能をゆっくりと見てきました。

上記の理由により、調整なしのインプレース展開は基本的に信頼できません。 この機能は歴史的に信頼性が低く、ASP.NET on .NET Frameworkで多くの問題を引き起こしているため、シャドウコピーを再度実装することはありません。 また、すべての.NETFrameworkがサポートされているフレームワークに依存する特定のタイプの展開でのみ機能します。 .NET Coreは、自己完結型の単一ファイルをサポートしているため、サポートがはるかに困難です。 上記の提案でさえ、それらのケースをカバーしていません。

インプレース展開は可能な限りアトミックである必要があり、この問題に関する多くの問題は、バグとapp_offlineの検出とリサイクルの信頼性の欠如に起因すると考えているため、修正（およびpdbロック）に多くの時間を費やしました。

Webデプロイは、デプロイするのが理にかなっていると思われるフローを具体化する今日の唯一のツールですが、そのテクノロジーに閉じ込められているため、サーバーにftpデプロイする場合やファイル共有にコピーする場合は役に立ちません（ただし、たぶん......だろう）。

dotnetグローバルツールがここでの答えかもしれません。

これはCIサーバーで実行することです。 バイナリ/パッケージを宛先サーバーにどのようにプッシュしますか？

私はそうは思いません。 おそらくFTPとストレートコピーをサポートするでしょう。 それ以外のものは、おそらく独自のプロトコルです。

うまくいけば、FTPと言うときは、sshを介したftpも意味します。 そのようなツールは非常に価値があります。

うまくいけば、FTPと言うときは、sshを介したftpも意味します。 そのようなツールは非常に価値があります。

いいえ、ftpを意味しました。 しかし、私たちは理にかなったことは何でもします。 たぶん、ターゲットマシンで実行する必要があるコピーツールであることが最善です。 これにより、ビットをどこにでも送信する必要がなくなります。

また、IISに展開するためにWindowsマシンにSSHで接続していますか？

@davidfowlデプロイメントスロットのサポートを追加（オプトイン）してください。
https://github.com/dotnet/aspnetcore/issues/3719#issuecomment -473183712
https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -335666414

アプリケーションアセンブリをディスクからロードしてファイルをロックするのではなく、バイトとしてメモリにロードすることを検討する予定です。 これはほとんどの場合問題ないはずですが、場合によってはメモリ使用量が増える可能性が

さらに、それではダウンタイムをゼロにすることはできません。

モジュールでそのような機能に投資する方法はありません。

うまくいけば、FTPと言うときは、sshを介したftpも意味します。 そのようなツールは非常に価値があります。

いいえ、ftpを意味しました。 しかし、私たちは理にかなったことは何でもします。 たぶん、ターゲットマシンで実行する必要があるコピーツールであることが最善です。 これにより、ビットをどこにでも送信する必要がなくなります。

また、IISに展開するためにWindowsマシンにSSHで接続していますか？

はい。 CI / CDを使用し、LinuxシステムとWindowsシステムの両方にデプロイするため、Windowsボックスにopensshをインストールする方がはるかに簡単でした。

$ appPool = 'デフォルト'
Stop-WebAppPool -Name $ appPool -Passthru
...デプロイ...

Start-WebAppPool -Name $ appPool -Passthru
...デプロイ....。

または

$ appPool = 'デフォルト'
Stop-WebAppPool -Name $ appPool
while（（Get-WebAppPoolState -Name $ appPool）.Value -ne'Stop '）{
スリープ1＃second
}
...デプロイ...

Start-WebAppPool -Name $ appPool
while（（Get-WebAppPoolState -Name $ appPool）.Value -ne'Start '）{
スリープ1＃second
}

...デプロイ....。

貧しい人々の展開スロット
約1年前に、2つのサイトルートフォルダーの作成について投稿し、IISサイト用に構成されたそのうちの1つへのシンボリックリンクポイントを設定しました。
利点は、他のより単純なソリューションと比較して、ダウンタイムが少ないことです。
オーバーラップリサイクルが有効になっている場合、ダウンタイムは発生せず、とにかく最初のリクエストに対するウォームアップペナルティのみが適用されます。

デプロイ/コピー操作が完了するまでにN秒かかる場合は、アプリプールをN秒間停止する必要はありません。
疑わしいアプリをオフラインでいじることはありません。
非アクティブなフォルダーにコピーし、ファイルがそこにあるときにシンボリックリンクを交換してから、アプリプールをリサイクルします。
アトミックデプロイ。ダウンタイムは発生せず、通常どおり最初のリクエストが遅くなります。

https://github.com/dotnet/aspnetcore/issues/3793#issuecomment -459870870

誰かがそれを試しましたか？
このようなものが機能する場合は、クライアント側のデプロイツールを使用してサービスに変えることができます。

• クライアント->サーバー非アクティブなフォルダ/共有は何ですか？
• S：ここ
• C：OKデプロイ/コピー
• S：symlinkを交換してリサイクル
• C：thx、http get / healthcheck（オプション）
• C：めちゃくちゃだ、ロールバックpls
• S：symlinkスワップ、リサイクル（ビジネスに戻る）
• C：動作するまで繰り返しすすぎます

そのため、展開のロックされたファイルにも問題があります。 アプリホスティングで。 アプリプールを停止しようとしましたが、ファイルはロックされたままです。 app_offline.htmをプッシュしようとしましたが、うまくいきませんでした。
また、app_offline.htmファイルの削除を管理したい場合は、program.csでアプリを起動するときに簡単に削除できます。 このようにして、開始時にオンラインになることがわかります。

私が直面している現在の問題は、dllがハングし、名前を変更してからファイルをコピーしても、名前が変更されたファイルに対して古いプロセスが実行されていることです。 したがって、再度デプロイしようとすると、ファイルの名前を再度変更する必要があります。 ファイル名の代わりに、ある種の日付を使用できると思います。
IISサーバーWindows2012R2ではこれにdotnetcore3.1.4を使用しています

@foxjazzアプリのプール/プロセスが停止した場合、ファイルはどのようにロックされますか？ 詳細を教えていただけますか？

@foxjazzアプリのプール/プロセスが停止した場合、ファイルはどのようにロックされますか？ 詳細を教えていただけますか？

使用済みのdllを削除しようとすると、画像には別のプロセスで使用されていると表示されます。
アプリプールはしばらくの間オフラインになっています。

タスクマネージャをチェックして、プロセスがまだ実行されているかどうかを確認します。 停止ボタンを押しても、すぐに終了するわけではありません。

タスクマネージャをチェックして、プロセスがまだ実行されているかどうかを確認します。 停止ボタンを押しても、すぐに終了するわけではありません。

上の写真はタスクマネージャーからのものです。 どちらかはわかりませんが、削除するとファイルが解放されます。 ハンドルを使用して、終了するpidを把握できると思います。 展開のためにこれらの長さに行く必要があるとは思いませんでした。 ハンドルによると、w3wp.exe2プロセスのファイルの1つがロックされています。 そのためのアプリプールがシャットダウンされていても。

本当に素晴らしいのは、プロセスを停止するためのルートがあることです。
api \ KillDeathKill
{{
Program.KillProcess（）
}

それはありそうもない。 ファイルはプロセスによってロックされています。 w3wpがそのプロセスである場合、最初から強制終了されていないか、同じファイルをロックしている別のpidで新しいプロセスがスピンアップされています。 そのため、ファイルをロックし、既存のプロセスを強制終了し、新しいビットをデプロイし、アプリをオフラインで削除する新しいプロセスがないことを確認するために、最初にアプリをオフラインにしていることを確認する必要があります

それはありそうもない。 ファイルはプロセスによってロックされています。 w3wpがそのプロセスである場合、最初から強制終了されていないか、同じファイルをロックしている別のpidで新しいプロセスがスピンアップされています。 そのため、ファイルをロックし、既存のプロセスを強制終了し、新しいビットをデプロイし、アプリをオフラインで削除する新しいプロセスがないことを確認するために、最初にアプリをオフラインにしていることを確認する必要があります

app_offline.htmが最初にダウンしていると言うとき。 はい、そうです。 getリクエストで確認できるステータスパスがあり、間違いなくオフラインです。 また、アプリプールを手動で停止しました。 しかし、プロセスw3wpはまだファイルをハングさせていました。

その後、プロセスは停止されませんでした

その後、プロセスは停止されませんでした

では、なぜプロセスを停止するのではなく、アプリプールを停止するのでしょうか。

アプリプールはプロセスを表しており、アプリプールを停止すると、プロセスが停止します。 ファイルをロックするプロセスがない場合、ファイルをロックすることはできないため、他の理論の1つがより可能性が高いようです。

アプリプールはプロセスを表しており、アプリプールを停止すると、プロセスが停止します。 ファイルをロックするプロセスがない場合、ファイルをロックすることはできないため、他の理論の1つがより可能性が高いようです。

はぁ、たわごとを言った。 私はあなたをパンキングしているように見えるつもりはありません。 すべてのドキュメントで宣伝されているように、アプリプールの停止が機能していないと言っています。 プロセスはたわごとではなく、90秒後でも実行されています。 アプリプールが停止していることがはっきりとわかる場合でも、ファイルはロックされています。 このプロセスには、データを取得するためのシングルトンが含まれています。 そして他のコントローラー。 ロックされたファイルに基づいてプロセスをシャットダウンするスクリプトがあると便利です。 その後、恐れることなく展開できました。 名前の変更も機能する場合があります。 ファイルの名前を変更できます。 （dotnet core 3.1.4）フレーバー

約1年前に、2つのサイトルートフォルダーの作成について投稿し、IISサイト用に構成されたそのうちの1つへのシンボリックリンクポイントを設定しました。

誰かがそれを試しましたか？
このようなものが機能する場合は、クライアント側のデプロイツールを使用してサービスに変えることができます。

@ CJHarmath-私はこれを試してみましたが、以下で使用しているコードを変更しました。 非常にうまく機能します、ありがとう！

更新をさらに公開した場合は、クライアント展開ツールを検討するかもしれませんが、実際には、IISサーバーにリモートシェルを配置し、PowerShellスクリプトを実行してそれを反転させることができます。
psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

# FlipSymLink.ps1

Import-Module WebAdministration # run as admin
# create 2 site root directories
$a = 'C:\Websites\MySiteA'
$b = 'C:\Websites\MySiteB'
$appRoot  = 'C:\Websites\MySite'
$appName  = 'MyAppName'
$siteName = 'MySiteName'
$poolName = "MyPoolName"
New-Item -Type Directory $a -ErrorAction SilentlyContinue
New-Item -Type Directory $b -ErrorAction SilentlyContinue

# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $appRoot -Target $a -Name A -ErrorAction SilentlyContinue
New-Item -Type SymbolicLink -Path $appRoot -Target $b -Name B -ErrorAction SilentlyContinue

# point the site root to the symlink
$currentPath = (Get-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath)
if ($currentPath -eq "$appRoot\A") {
    Write-Host "Switched to B"
    New-Item $b\active.txt
    Remove-Item $a\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\B
} else {
    Write-Host "Switched to A"
    New-Item $a\active.txt
    Remove-Item $b\active.txt
    Set-ItemProperty "IIS:\Sites\$siteName\$appName" -name physicalPath -value $appRoot\A
}
Restart-WebAppPool -Name $poolName

psexec.exe \\IIS_SERVER cmd /c "powershell -noninteractive -file C:\FlipSymLink.ps1"

これはJEAエンドポイントに変換することもできるため、昇格されていないユーザーとしてflipを実行できます（CI / CDサーバーのデプロイ手順などから）
Invoke-Command -ComputerName IIS_SERVER -ConfigurationName IIS-Flip -ScriptBlock { Switch-SymlinkTarget -SiteName MySite}
承認された動詞であるため、 Flip代わりにSwitch使用しました。

承認された動詞であるため、 Flip代わりにSwitch使用しました。

Swapは、スロットを扱うときに使用される動詞です。ここで再利用するのは理にかなっているようです。

4年前に説明したのと同じ問題を抱えています。
これに関する更新はありますか？
新しいdllファイルをアップロードするためだけにリモートデスクトップを開きたくありません。

本番IISサーバーでFTPを使用して.NETCoreアプリケーションDLLファイルを上書きしようとすると、ファイルがロックされ、上書きできません。

新しいバージョンを展開するには、IISでアプリケーションを停止して（RDPを開いて）ロックを解除してから、上書きする必要があります。
アプリケーションを停止せずにデプロイすることはできません。

これに対する解決策はありますか？ ありがとう

ロードバランサーの背後でホストをオフラインにすることができず、より迅速に実行したい場合は、シンボリックリンクといくつかのPowerShellを使用する1つの方法があります。
こんなことを考えていました。

コピー+リサイクル中にアプリプールを停止する必要がないため、現在のリクエストを完了できるため、ダウンタイムが少なくなるため、ハードストップよりも高速です。

# Setup
Import-Module WebAdministration
# create 2 site root directories
$a = 'C:\inetpub\AspNetCoreSampleA'
$b = 'C:\inetpub\AspNetCoreSampleB'
$siteRoot = 'C:\inetpub\aspnetcoresample'
$siteName = 'AspNetCoreSample'
$poolName = "aspnetcore"
New-Item -Type Directory $a
New-Item -Type Directory $b
# create a symlink to targeting one side
New-Item -Type SymbolicLink -Path $siteRoot -Target $a
# point the site root to the symlink
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $siteRoot
# make sure it get's picked up
Restart-WebAppPool -Name $poolName

# this tells you the active side
Get-Item -Path $siteRoot | Select-Object -ExpandProperty target

# Flip the symlink
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
# at this point w3wp.exe still locks the current target folder until it's getting recycled
# Deploy new version to the symlink which is now pointing to the other side which should have no locks
robocopy \\myshare\myapp $siteRoot /mir
# recycle app pool, so it picks up the new files
Restart-WebAppPool -Name $poolName

# bonus point: rollback is easy
$current = (Get-Item -Path $siteRoot).Target
$newTarget = if ($current -eq $a) {$b} else {$a}
New-Item -Type SymbolicLink -Path $siteRoot -Target $newTarget -Force
Restart-WebAppPool -Name $poolName

ここに要点があります
https://gist.github.com/csharmath/b2af0f50700ce9fbdd8c5c3e582fd41b

これが私がねじれを解決したと思うものです。 ASP.NETでのみ試しましたが、ネットコアのホスティングモジュールでも同じように機能すると思います。 最初の実行ではサイトが少し停止するので、少し調整することをお勧めします。

param(
    [Parameter(Mandatory = $true)]
    [string] $iisRootPath,
    [Parameter(Mandatory = $true)]
    [string] $siteName,
    [Parameter(Mandatory = $true)]
    [string] $artifactPath,
    [Parameter(Mandatory = $false)]
    [string] $siteFolderName,
    [Parameter(Mandatory = $false)]
    [string] $appPoolName
)
Import-Module WebAdministration

#populate optional parameters
if (!($PSBoundParameters.ContainsKey('siteFolderName'))) { $siteFolderName = $siteName }
if (!($PSBoundParameters.ContainsKey('appPoolName'))) { $appPoolName = $siteName }

#set A, B and C paths
$a = "$iisRootPath\$siteFolderName" + 'A'
$b = "$iisRootPath\$siteFolderName" + 'B'
$c = "$iisRootPath\$siteFolderName"

#existence test
$cName = Get-Item -Path $c -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#get the shudown timeout for the app pool
$shutdownTimeout = Get-WebConfigurationProperty -Filter 'system.web/httpRuntime' -PSPath "IIS:\Sites\$siteName" -Name shutdownTimeout | Select-Object -ExpandProperty Value

#create symlink, if symlink source is an existing directory, rename existing 
if($cName -eq $null) 
{
    Write-Output "Creating SymbolicLink $c -> $a" 
    New-Item -Type SymbolicLink -Path $c -Target $a
} 
else
{
    #directories don't have a target property
    $cTarget = Get-Item -Path $c | Select-Object -ExpandProperty target -ErrorAction SilentlyContinue

    #this is a directory, rename and create symlink
    if($cTarget -eq $null)
    {
        #restart AppPool first so no locked files
        #Write-Output "Restarting AppPool $appPoolName" 
        #Restart-WebAppPool -Name $appPoolName

        #stop AppPool first so no locked files
        Write-Output "Stopping AppPool $appPoolName" 
        Stop-WebAppPool -Name $appPoolName

        #sleep for shutdownTimeout
        Write-Output "Sleeping for $shutdownTimeout" 
        Start-Sleep -Seconds (([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds) * 1.1)

        try {
             #if the rename fails, there are files in use. stop the script
            $newName = $siteFolderName + 'A'
            Write-Output "Renaming $c to $newName" 
            Rename-Item -Path $c -NewName $newName -ErrorAction Stop
        }
        catch {
            Write-Error -Message "Failed to rename $c to $newName due to files in use."

            #start AppPool 
            Write-Output "Starting AppPool $appPoolName due to failed folder rename. Consider trying again durring a time with reduced traffic." 
            Start-WebAppPool -Name $appPoolName

        }

        #create symlink
        Write-Output "Creating SymbolicLink $c -> $a" 
        New-Item -Type SymbolicLink -Path $c -Target $a

        #start AppPool 
        Write-Output "Starting AppPool $appPoolName" 
        Start-WebAppPool -Name $appPoolName

        #copy a to b to pick up directory permissions
        if($bName -eq $null) 
        {
            Write-Output "Copying Directory $a to $b"  
            robocopy $a $b /e /sec /sl
        }
    }
}

#existence test
$aName = Get-Item -Path $a -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue
$bName = Get-Item -Path $b -ErrorAction SilentlyContinue | Select-Object -ExpandProperty name -ErrorAction SilentlyContinue

#create if needed
if($aName -eq $null) 
{
    Write-Output "Creating Directory $a"  
    New-Item -Type Directory $a 
}
if($bName -eq $null) 
{
    Write-Output "Creating Directory $b"  
    New-Item -Type Directory $b 
}

#make sure site pointing to symlink
Write-Output "Pointing Website $siteName to Path $c" 
Set-ItemProperty "IIS:\Sites\$siteName" -name physicalPath -value $c

#restart so we know it's loading from symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

#sleep for shutdownTimeout 
Write-Output "Sleeping for $shutdownTimeout" 
Start-Sleep -Seconds ([System.TimeSpan]::Parse("$shutdownTimeout").TotalSeconds)

#get current symlink target and set new target
Get-Item -Path $c | Select-Object -ExpandProperty target
$current = (Get-Item -Path $c).Target
$newTarget = if ($current -eq $a) {$b} else {$a}

$fileOrDirectoryName = Get-Item $artifactPath | Select-Object -ExpandProperty name

#test for .zip
if(($fileOrDirectoryName).ToLower().EndsWith(".zip") -eq $true)
{
    #copy to temp location
    $guid = [System.Guid]::NewGuid()
    $tempPath = "$iisRootPath\temp-$guid"
    $tempDest = "$iisRootPath\temp-dest-$guid"

    Write-Output "Creating temp directory $tempPath" 
    New-Item -Type Directory $tempPath

    $artifactDirectory = [System.IO.Path]::GetDirectoryName($artifactPath)
    $artifactFile = [System.IO.Path]::GetFileName($artifactPath);

    #TODO: first robocopy arg needs to be a directory, not a file
    Write-Output "Copying archive from $artifactPath to $tempPath" 
    robocopy $artifactDirectory $tempPath $artifactFile

    #extract to temp destination (seems a failed extract can leave empty folders)
    Write-Output "Extracting archive to $tempDest" 
    Expand-Archive -Path "$tempPath\$fileOrDirectoryName" -DestinationPath $tempDest -Force

    #copy from temp destination to destination
    Write-Output "Copying files from $tempDest to $newTarget" 
    robocopy $tempDest $newTarget /e

    #delete temp directory
    Write-Output "Removing temp directory $tempPath" 
    Remove-Item -Path $tempPath -Recurse -Force

    #delete temp directory
    Write-Output "Removing temp directory $tempDest" 
    Remove-Item -Path $tempDest -Recurse -Force
}
else 
{
    #copy new files
    Write-Output "Copying files from $artifactPath to $newTarget" 
    robocopy $artifactPath $newTarget /e
}

#swap symlink
Write-Output "Pointing SymbolicLink $c -> $newTarget" 
New-Item -Type SymbolicLink -Path $c -Target $newTarget -Force

#restart so it loads from newly swapped symlink
Write-Output "Restarting AppPool $appPoolName" 
Restart-WebAppPool -Name $appPoolName

@LucidObscurityそれは何ですか？ cmdコード？ そのコードはどこに追加する必要がありますか？
ありがとう

プロセスがリリースするまで、 msdeployコマンドの再試行回数（パラメーター： -retryAttempts:X ）または再試行時間間隔（パラメーター： -retryInterval:XXXX ）を増やすというアイデアはどうでしょうか。ファイルロック？

@davidfowlは正しいと思います。プロセスはまだそこにあり、ファイルをロックします。 IISをリセットしても役に立ちませ
ローカルの私にとっては、それほど長く待ちたくないので、このシャットダウン時間制限（秒）を5に更新し、プロジェクトファイルを更新してビルド前にapp_offline.htmを生成し、ビルド後に削除しました。 それはうまくいきます。
サーバーの場合、 msdeployを使用してapp_offline.htmを削除します。 msdeployでは、ファイルがロックされている場合は再試行しますが、90秒前に諦めたため、デプロイを再度トリガーする必要があり、2回目の試行で機能します。

これに関する更新はありますか？ この新しいリリースの準備はいつですか？

お問い合わせいただきありがとうございます。
この問題は、将来の評価/検討のためにNext sprint planningマイルストーンに移動します。 次のマイルストーンの作業を計画するときに、リクエストを評価します。 次に何が予想され、この問題がどのように処理されるかについて詳しくは、トリアージプロセスの詳細をこちらでご覧ください。

今週、.NET4.5.2アプリケーションを.NET5.0に変換した後、この問題について発見しました。 これを克服する別のアプローチがあります。 IISサーバーで実行されているWindowsサービスを作成しました。 そのサービスでは、カスタムポートで実行されている単純なHTTPサーバーがあります。 Webアプリケーションは、そのサーバーに対してPOSTリクエストを実行して、アップグレードを開始できます。 アプリプールを停止し、そのアプリケーションのすべてのプロセスを強制終了し、現在のリリースのバックアップを作成し、現在のリリースを削除し、upgradepackageをダウンロードして抽出します。 その後、アプリプールを再開します。

上記のWindowsサービスがフェッチするリポジトリにプッシュされるアップグレードパッケージを作成するために、単純なWindowsフォームアプリケーションを作成しました。