診断とインストルメンテーション
ネイティブ AOT は、すべてではありませんが、診断およびインストルメンテーションの機能の一部を CoreCLR と共有します。 CoreCLR には診断ユーティリティが豊富に用意されているため、CoreCLR で問題を診断し、デバッグすることが適切な場合があります。 トリミング互換アプリには動作の違いがあってはいけないため、多くの場合、調査は両方のランタイムに適用されます。 ただし、一部の情報は発行後にしか収集できないため、ネイティブ AOT では発行後の診断ツールも用意されています。
.NET 8 ネイティブ AOT 診断サポート
次の表は、ネイティブ AOT デプロイでサポートされる診断機能をまとめたものです。
| 機能 | 完全にサポートされています | 一部サポートされています | サポートされていません |
|---|---|---|---|
| 監視とテレメトリ | 部分的にサポート | ||
| 開発時の診断 | 完全にサポート | ||
| ネイティブ デバッグ | 部分的にサポート | ||
| CPU プロファイリング | 部分的にサポート | ||
| ヒープ分析 | サポートされていません |
監視とテレメトリ
.NET 8 以降、ネイティブ AOT ランタイムでは、EventPipe がサポートされています。これは、多くのログやトレース ライブラリで使用される基本レイヤーです。 EventSource.WriteEvent などの API を介して EventPipe と直接やり取りすることも、その上に構築されたライブラリ (OpenTelemetry など) を使用することもできます。 EventPipe のサポートにより、dotnet-trace、dotnet-counters、dotnet-monitor などの .NET 診断ツールがネイティブ AOT または CoreCLR アプリケーションとシームレスに連携できるようになります。 EventPipe は、ネイティブ AOT のオプションのコンポーネントです。 EventPipe サポートを含めるには、EventSourceSupport MSBuild プロパティを true に設定します。
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
ネイティブ AOT は、いくつかのよく知られたイベント プロバイダーの部分的なサポートを提供します。 すべてのランタイム イベントがネイティブ AOT でサポートされているわけではありません。
開発時の診断
.NET CLI ツール (dotnet SDK) と Visual Studio には、build と publish 用の個別のコマンドが用意されています。 build (または Visual Studio の Start) では CoreCLR が使用されます。 ネイティブ AOT アプリケーションを作成するのは publish だけです。 アプリをネイティブ AOT として公開すると、ネイティブ コードに Ahead-Of-Time (AOT) コンパイルされたアプリが生成されます。 前述したように、すべての診断ツールが .NET 8 で公開されたネイティブ AOT アプリケーションとシームレスに動作するわけではありません。 ただし、開発者はアプリケーション構築段階ですべての .NET 診断ツールを利用できます。 通常どおりアプリケーションの開発、デバッグ、テストを行い、最後の手順の 1 つとしてネイティブ AOT を使用して動作するアプリを公開することをお勧めします。
ネイティブ デバッグ
Visual Studio 内や、dotnet run、dotnet build、dotnet test のいずれかを使用して、開発中にアプリを実行すると、既定で CoreCLR 上で実行されます。 ただし、PublishAot がプロジェクト ファイルに存在する場合、CoreCLR とネイティブ AOT の動作は同じである必要があります。 この特性があるので、開発とテストに標準の Visual Studio マネージド デバッグ エンジンを使用できます。
発行後、ネイティブ AOT アプリケーションは真のネイティブ バイナリになります。 マネージド デバッガーはそれらに対して機能しません。 ただし、ネイティブ AOT コンパイラによって、任意のプラットフォーム上のネイティブ デバッガー (たとえば、Windows 上の WinDbg または Visual Studio、Unix 系システム上の gdb または lldb) でデバッグできる完全にネイティブな実行可能ファイルが生成されます。
ネイティブ AOT コンパイラによって、行番号、型、ローカル、パラメータに関する情報が生成されます。 ネイティブ デバッガーを使用すると、スタック トレースと変数の検査、ソース行へのステップインまたはステップオーバー、または行ブレークポイントの設定が行えます。
マネージド例外をデバッグするには、マネージド例外がスローされるたびに呼び出される RhThrowEx メソッドにブレークポイントを設定します。 この例外は、rcx または x0 レジスタに格納されます。 お使いのデバッガーで C++ オブジェクトの表示がサポートされている場合は、レジスタを S_P_CoreLib_System_Exception* にキャストして、例外に関する詳細情報を表示できます。
ネイティブ AOT アプリケーションのダンプ ファイルを収集するには、.NET 8 でいくつかの手順を手動で行う必要があります。
Visual Studio 固有の注意事項
ネイティブ AOT でコンパイルされた実行可能ファイルを Visual Studio IDE で開くと、Visual Studio デバッガーで起動できます。 実行可能ファイル自体を Visual Studio で開く必要があります。
例外がスローされるたびに中断するブレークポイントを設定するには、[デバッグ] > [Windows] メニューから [ブレークポイント] オプションを選択します。 新しいウィンドウで、[新規] > [関数] ブレークポイントを選択します。 RhThrowEx を関数名として指定し、[言語] オプションは [すべての言語] のままにします (C# を選択しないでください)。
スローされた例外を確認するには、デバッグを開始し ([デバッグ] > [デバッグの開始] または F5 キー)、ウォッチ ウィンドウ ([デバッグ] > [Windows] > [ウォッチ]) を開き、ウォッチの 1 つとして式 (S_P_CoreLib_System_Exception*)@rcx を追加します。 このメカニズムは、RhThrowEx が呼び出された時点で、x64 CPU レジスタ RCX にスローされた例外が含まれているという事実を利用しています。 イミディエイト ウィンドウに式を貼り付けることもできます。構文はウォッチの場合と同じです。
シンボル ファイルの重要度
発行時に、ネイティブ AOT コンパイラによって実行可能ファイルとシンボル ファイルの両方が生成されます。 ネイティブ デバッグと、プロファイルなどの関連アクティビティには、ネイティブ シンボル ファイルへのアクセスが必要です。 このファイルが存在しない場合、結果が低下したり破損したりする可能性があります。
シンボル ファイルの名前と場所については、「ネイティブ デバッグ情報」を参照してください。
CPU プロファイリング
PerfView や Perf などのプラットフォーム固有のツールを使用して、ネイティブ AOT アプリケーションの CPU サンプルを収集できます。
ヒープ分析
マネージド ヒープ分析は現在、ネイティブ AOT ではサポートされていません。 dotnet-gcdump、PerfView、Visual Studio ヒープ分析ツールなどのヒープ分析ツールは、.NET 8 のネイティブ AOT では機能しません。
.NET