.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 にあります。