Performance | The .NET Blog

.NET 11がついにプロセスAPIを修正

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

プロセスを起動して出力をキャプチャする必要があった .NET 開発者は誰もが、同じ危険な定型コードの何らかのバリエーションを書いてきました：stdout の非同期読み取り、stderr の非同期読み取り、WaitForExitAsync、両方のストリームをドレインするのを忘れるとデッドロックが発生する。これは長年知られている落とし穴です。

.NET 11 がついにこれを適切に修正します。

RunAndCaptureTextAsync

主要な追加：プロセスを起動し、stdout と stderr をキャプチャし、デッドロックなしに終了を待機する単一の静的メソッド。

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

1回の呼び出し。手動ストリームドレインなし。注意深く配置した WaitForExit なし。何かを実行してその出力を得るだけなら、これが求めていた API です。

出力をキャプチャせずに終了を待ちたい場合のために Process.RunAsync もあります。

KillOnParentExit

起動されたプロセスでよくある問題：親プロセスがクラッシュまたは終了された場合、子プロセスはオーファンとして実行し続けます。KillOnParentExit を使用すると、プロセス起動時に親プロセスが終了したときに子プロセスも終了することをあらかじめ宣言できます。

この機能はプラットフォーム固有の方法（Windows ではジョブオブジェクト、Linux では prctl）で存在していましたが、.NET から使用するには p/invoke またはサードパーティライブラリが必要でした。今では ProcessStartInfo のファーストクラスのプロパティになりました。

SafeProcessHandle ベースの API

新しい軽量 API サーフェスは、完全な Process クラスではなく SafeProcessHandle を中心に構築されています。完全な Process クラスは多くの状態を抱えており、トリムが困難です — SafeProcessHandle パスは出力サイズを最小化する必要があるアプリケーション（WASM、ネイティブ AOT）にとってよりトリマーフレンドリーです。

ハンドル継承の完全制御

このアップデートでは、子プロセスが継承するハンドルと標準ハンドルのリダイレクト方法に対するきめ細かい制御も追加されます。以前は stdin/stdout/stderr をリダイレクトできましたが、OS レベルでどのハンドルを継承するかを正確に指定することはできませんでした。新しい API はそのコントロールを公開します。

なぜ重要か

Process クラスはツール、ビルドシステム、テストランナー、および他の実行ファイルを呼び出すあらゆるアプリケーションで使用されています。古い API サーフェスは .NET Framework 時代のものであり、時代遅れになっていました。これは破壊的変更ではありません — 古い API は引き続き動作します — しかし新しいコードは新しいサーフェスを優先すべきです。

トリムされたアプリケーションや AOT コンパイルシナリオでは、SafeProcessHandle パスが特に歓迎されます。古い Process クラスはトリムを複雑にするリフレクション重いコードを多く持ち込んでいました。

元の記事: Process API Improvements in .NET 11

Copilot Studio が .NET 10 WebAssembly に移行して 20% 高速化した方法

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

Copilot Studio チームは、すべての Blazor WASM 開発者が気になっていたことを実行しました：本番アプリケーションを .NET 8 から .NET 10 に実際にアップグレードし、結果を測定しました。投稿には具体的な数値が含まれており、それは珍しく本当に有用です。

アップグレードは退屈でした（それは良いことです）

ターゲットフレームワークを更新し、パッケージ参照を更新し、破壊的変更を修正する。それだけです。.NET 10 ビルドは今や本番環境で稼働しています。移行自体は興味深い部分ではありませんでした—.NET 10 の変更がそうです。

自動アセットフィンガープリント

以前は、WASM アプリを配布するには、キャッシュバスティングのために公開されたアセットを SHA256 ハッシュで名前変更するカスタムスクリプトを書く必要がありました。Copilot Studio にはこれをまさに行う PowerShell スクリプトがありました—ファイルの名前変更、JavaScript ローダーへの integrity 属性の注入、すべてを手動で管理する。

.NET 10 では、これらすべてが組み込まれています。公開されたアセットは自動的にフィンガープリントされ、dotnet.js から直接インポートされ、手動介入なしに整合性検証されます。チームはリネームスクリプトを削除しました。

スコープの小さな変更、複雑さの大幅な削減。

WasmStripILAfterAOT がデフォルトで有効に

.NET 8 では、AOT でコンパイルされたアセンブリから IL を削除することはオプトインでした。.NET 10 ではデフォルトです。AOT コンパイル後、元の IL バイトコードは出力から削除されます—ランタイムでは必要なく、それを保持することはパッケージサイズを無意味に膨らませていました。

Copilot Studio は特定の最適化を使用しています：JIT エンジン（高速起動）と AOT エンジン（最大ステディステートパフォーマンス）の両方を配布し、両方を並行して読み込み、準備ができたら JIT から AOT に引き渡します。また、2つのエンジン間で同一のファイルを重複排除します。

新しい IL 削除動作は、AOT アセンブリが JIT の対応物とビット単位で一致しなくなることを意味し、そのため重複排除されるファイルが少なくなります：

.NET 8：59 個の共有ファイル
.NET 10：22 個の共有ファイル

結果として：AOT エンジンのパッケージサイズが約 15% 大きくなります。AOT ダウンロードは高速 LAN で約 6% 遅く、4G で約 17% 遅くなります。しかし、これはすべてアプリがすでにインタラクティブになった後、バックグラウンドで行われます。

パフォーマンス数値

重要なのはここです：

最初の呼び出しで 約 20% 高速（コールドパス）
後続の呼び出しで 約 5% 高速（ウォームパス）

改善は「大きなボット」で最も顕著です—AOT コンパイルされたコードが支配する大規模で複雑なエージェント。より単純なワークフローではゲインは小さくなります。

まだ .NET 8 を使用している場合

移行の話は本当にシンプルです：<TargetFramework> を更新し、パッケージ参照を更新し、カスタムフィンガープリントスクリプトを削除すれば、自動的に WasmStripILAfterAOT の恩恵を受けられます。AOT でコンパイルしている場合は、同様のパフォーマンス向上が期待できます。

投稿からの注意事項：.NET WASM ランタイムを WebWorker の内部で読み込む場合は、初期化時に dotnetSidecar = true を設定してください。

元の投稿：Copilot Studio gets faster with .NET 10 on WebAssembly