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 を設定してください。
