.NET 11 Preview 3 の dotnet watch: Aspire ホスト、クラッシュリカバリー、まともな Ctrl+C
.NET 11 Preview 3 で dotnet watch が Aspire app host 統合、クラッシュ後の自動再起動、Windows desktop アプリ向けの修正された Ctrl+C 処理を得ます。
dotnet watch はいつも .NET インナーループの静かな働き馬でした。ファイルが変わるとアプリを再ロードし、できるところで hot reload を適用し、できないときは道を譲ります。.NET 11 Preview 3 (2026 年 4 月 14 日出荷) は 3 つの具体的な痛点でツールを前進させます: 分散アプリを動かす、クラッシュを生き残る、Windows desktop ターゲットでの Ctrl+C への対処です。
Aspire app host が今やクリーンに watch される
Preview 3 まで、dotnet watch 配下で Aspire app host を走らせるのはぎこちないものでした。Aspire は複数の子プロジェクトをオーケストレートしますが、watcher はそのモデルを理解していなかったので、ファイル変更はホストだけを rebuild するか、トポロジー全体をゼロからリスタートさせるかのどちらかでした。
Preview 3 は dotnet watch を Aspire app model に直接配線します:
cd src/MyApp.AppHost
dotnet watch
MyApp.ApiService のファイルを編集すれば、watcher はその service にだけ変更を適用し、Aspire トポロジーの残りを生かしたままにします。ダッシュボードは立ったままで、依存コンテナは走り続け、プロジェクトごとに秒数ではなく、変更ごとの boot time 秒数を失うだけで済みます。
microservice-heavy な solution にとって、これは dotnet watch が nice-to-have であることと、デフォルトの作業方法であることの違いです。
クラッシュ後の自動再起動
2 つ目の見出しはクラッシュリカバリーです。以前は、watch 対象のアプリがハンドルされていない例外を投げて死ぬと、dotnet watch はクラッシュメッセージで駐車して手動の再起動を待っていました。次のキーストロークで fix を保存しても、Ctrl+R を叩くまで何も起きませんでした。
Preview 3 ではその挙動が反転します。爆発する endpoint を取ります:
app.MapGet("/", () =>
{
throw new InvalidOperationException("boom");
});
アプリを一度クラッシュさせ、fix を保存すると、次の関連ファイル変更で dotnet watch が自動的に再起動します。アプリが non-zero で終了すると決めただけで feedback loop を失うことはありません。同じ挙動は startup でのクラッシュもカバーし、以前は hot reload がアタッチする前に watcher が詰まっていた状況も解決します。
これはすでに存在する watch-wide な “rude edit” ハンドリングとうまく組み合わさります: hot reload がまず試み、非サポートの edit では restart にフォールバックし、そして今や crash 後にも restart にフォールバックします。3 つのパス、一貫した結果 1 つ: アプリが戻ってくる、です。
Windows desktop アプリでの Ctrl+C
3 つ目の修正は小さいですが慢性的でした: WPF と Windows Forms アプリの dotnet watch での Ctrl+C です。以前は desktop プロセスを孤児にしたり、watcher から切り離したり、モーダルウィンドウ内でハングさせたりしていました。Preview 3 はシグナルハンドリングを再配線し、Ctrl+C が watcher と desktop プロセスの両方を順番に分解し、Task Manager に dotnet.exe のゾンビエントリが積み上がらないようにします。
dotnet watch 下で WPF シェルを走らせる場合:
dotnet watch run --project src/DesktopShell
Ctrl+C を 1 回叩けば、シェルと watcher の両方がクリーンに終了します。基本的に聞こえますし、実際そうですが、以前の挙動は多くのチームが desktop プロジェクトで dotnet watch を完全に避ける主な理由でした。
この 3 つがなぜ一緒に重要か
各変更はそれ単体では控えめです。組み合わせると、dotnet watch をプロジェクト単位のヘルパーから、Aspire トポロジーを一日中ホストでき、たまのクラッシュを吸収し、終わったときに自分の後片付けができるセッション全体のハーネスに移します。インナーループは目に見えて脆くなくなりました。
リリースノートは .NET ブログ にあり、SDK のセクションは What’s new in the SDK and tooling for .NET 11 にあります。
Comments
Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.