Diagnose und Instrumentation
Die native AOT hat einige, aber nicht alle Diagnose- und Instrumentierungsfunktionen mit CoreCLR gemeinsam. Aufgrund der umfangreichen Auswahl an Diagnoseprogrammen von CoreCLR ist es manchmal hilfreich, Probleme in CoreCLR zu diagnostizieren und zu debuggen. Apps, die kürzungskompatibel sind, sollten keine Verhaltensunterschiede aufweisen, daher gelten die Untersuchungen oft für beide Laufzeiten. Dennoch können einige Informationen erst nach der Veröffentlichung gesammelt werden, sodass native AOT auch nach der Veröffentlichung Diagnosetools bereitstellen.
Unterstützung der nativen AOT-Diagnose in .NET 8
In der folgenden Tabelle sind Diagnosefeatures zusammengefasst, die für native AOT-Bereitstellungen unterstützt werden:
| Feature | Vollständig unterstützt | Teilweise unterstützt | Nicht unterstützt |
|---|---|---|---|
| Einblick und Telemetrie | Teilweise unterstützt | ||
| Entwicklungszeitdiagnose | Vollständig unterstützt | ||
| Systemeigenes Debuggen | Teilweise unterstützt | ||
| CPU-Profilerstellung | Teilweise unterstützt | ||
| Heapanalyse | Nicht unterstützt |
Einblick und Telemetrie
Ab .NET 8 unterstützt die native AOT-Laufzeit EventPipe, das von vielen Protokollierungs- und Ablaufverfolgungsbibliotheken als Basisebene verwendet wird. Sie können SChnittstellen mit EventPipe direkt über API, wie EventSource.WriteEvent, erstellen oder integrierte Bibliotheken wie z. B. OpenTelemetry verwenden. Die EventPipe-Unterstützung ermöglicht auch den meisten .NET-Diagnosetools wie dotnet-trace, dotnet-counters und dotnet-monitor die nahtlose Zusammenarbeit mit nativen AOT- oder CoreCLR-Anwendungen. EventPipe ist eine optionale Komponente in nativem AOT. Legen Sie für EventPipe-Unterstützung die MSBuild-Eigenschaft EventSourceSupport auf true fest.
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
Natives AOT unterstützt einige bekannte Ereignisanbieter teilweise. Nicht alle Laufzeitereignisse werden in nativem AOT unterstützt.
Entwicklungszeitdiagnose
Das .NET CLI-Tooling (dotnet SDK) und Visual Studio bieten separate Befehle für build und publish. build (oder Start in Visual Studio) verwendet CoreCLR. Nur publish erstellt eine native AOT-Anwendung. Wenn Sie Ihre App als native AOT-Bereitstellung veröffentlichen, entsteht eine App, die im Voraus (Ahead-Of-Time, AOT) in nativem Code kompiliert wurde. Wie bereits erwähnt, funktionieren nicht alle Diagnosetools nahtlos mit veröffentlichten nativen AOT-Anwendungen in .NET 8. Alle .NET-Diagnosetools sind jedoch während der Anwendungserstellung für Entwickelnde verfügbar. Es wird empfohlen, die Anwendungen wie gewohnt zu entwickeln, zu debuggen und zu testen und die funktionierende App mit nativem AOT in einem der letzten Schritte zu veröffentlichen.
Systemeigenes Debuggen
Wenn Sie Ihre App während der Entwicklung ausführen, z. B. in Visual Studio oder mit dotnet run, dotnet build, oder dotnet test wird sie standardmäßig auf CoreCLR ausgeführt. Wenn PublishAot jedoch in der Projektdatei vorhanden ist, sollte das Verhalten zwischen CoreCLR und Native AOT identisch sein. Mit dieser Eigenschaft können Sie die standardmäßige verwaltete Debug-Engine von Visual Studio für Entwicklung und Tests verwenden.
Nach der Veröffentlichung sind native AOT-Anwendungen echte systemeigene Binärdateien. Der verwaltete Debugger funktioniert dafür nicht. Der Native AOT-Compiler erzeugt jedoch vollständig native ausführbare Dateien, die von nativen Debuggern auf der Plattform Ihrer Wahl debuggt werden können (z. B. WinDbg oder Visual Studio auf Windows und gdb oder lldb auf Unix-ähnlichen Systemen).
Der native AOT-Compiler generiert Informationen zu Zeilennummern, Typen, lokalen Variablen und Parametern. Mit dem systemeigenen Debugger können Sie die Stapelablaufverfolgung und Variablen prüfen, zeilenweise oder über Quellzeilen wechseln oder Zeilenumbrüche festlegen.
Um verwaltete Ausnahmen zu debuggen, legen Sie einen Haltepunkt für die Methode RhThrowEx fest, der immer dann aufgerufen wird, wenn eine verwaltete Ausnahme ausgelöst wird. Die Ausnahme wird im Verzeichnis rcx oder x0 gespeichert. Wenn Ihr Debugger das Anzeigen von C++-Objekten unterstützt, können Sie das Register in S_P_CoreLib_System_Exception* umwandeln, um weitere Informationen zur Ausnahme anzuzeigen.
Das Sammeln einer Abbilddatei für eine native AOT-Anwendung umfasst einige manuelle Schritte in .NET 8.
Visual Studio-spezifische Hinweise
Sie können eine native AOT-kompilierte ausführbare Datei unter dem Visual Studio-Debugger starten, indem Sie diese in der Visual Studio-IDE öffnen. Sie müssen die ausführbare Datei selbst in Visual Studio öffnen.
Wenn Sie einen Haltepunkt festlegen möchten, der bei jedem Auslösen einer Ausnahme unterbrochen wird, wählen Sie im Menü Windows > debuggen die Option Haltepunkte aus. Wählen Sie im neuen Fenster die Neue >Haltepunkt-Funktion aus. Geben Sie RhThrowEx als Funktionsname an und lassen Sie die Option Sprache bei Alle Sprachen (nicht C# auswählen).
Um zu sehen, welche Ausnahme ausgelöst wurde, starten Sie das Debuggen (Debug >Debugging starten oder F5), öffnen Sie das Überwachungsfenster (Debug> Fenster > Überwachung), und fügen Sie den folgenden Ausdruck als eines der Überwachungselemente hinzu: (S_P_CoreLib_System_Exception*)@rcx. Dieser Mechanismus nutzt die Tatsache, dass dem Zeitpunkt RhThrowEx aufgerufen wird und dass das x64 CPU-Register RCX die ausgelöste Ausnahme enthält. Sie können den Ausdruck auch in das Direktfenster einfügen; der Syntax entspricht dem für die Überwachung.
Bedeutung der Symboldatei
Bei der Veröffentlichung erzeugt der native AOT-Compiler sowohl eine ausführbare Datei als auch eine Symboldatei. Systemeigenes Debuggen und zugehörige Aktivitäten wie Profilerstellung erfordern Zugriff auf die systemeigene Symboldatei. Wenn diese Datei nicht vorhanden ist, kann es sein, dass Sie schlechtere oder fehlerhafte Ergebnisse erhalten.
Informationen zum Namen und Speicherort der Symboldatei finden Sie unter Systemeigene Debuginformationen.
CPU-Profilerstellung
Zum Sammeln von CPU-Stichproben einer nativen AOT-Anwendung können plattformspezifische Tools wie PerfView und Perf verwendet werden.
Heapanalyse
Die verwaltete Heap-Analyse wird derzeit in Native AOT nicht unterstützt. Heapanalysetools wie dotnet-gcdump, PerfView- und die Heapanalysetools von Visual Studio funktionieren in nativem AOT in .NET 8 nicht.
