Diagnostica e strumentazione

Native AOT condivide con CoreCLR alcune funzionalità di diagnostica e strumentazione, anche se non tutte. Data la vasta selezione di strumenti di diagnostica di CoreCLR, a volte è appropriato diagnosticare ed eseguire il debug dei problemi in CoreCLR. Le app compatibili con il trim non devono avere differenze funzionali, quindi le indagini spesso si applicano a entrambi i runtime. Tuttavia, alcune informazioni possono essere raccolte solo dopo la pubblicazione, quindi Native AOT fornisce anche strumenti di diagnostica post-pubblicazione.

Supporto di diagnostica Native AOT di .NET 8

La tabella seguente riepiloga le funzionalità di diagnostica supportate per le distribuzioni Native AOT:

Funzionalità	supporto completo	Parzialmente supportato	Non supportato
Osservabilità e telemetria		✔️Parzialmente supportato
Diagnostica in fase di sviluppo	✔️Completamente supportato
Debug nativo		✔️Parzialmente supportato
Profilatura CPU		✔️Parzialmente supportato
Analisi dell'heap			❌Non supportato

Osservabilità e telemetria

A partire da .NET 8, il runtime Native AOT supporta EventPipe, ovvero il livello di base usato da molte librerie di registrazione e traccia. È possibile interfacciarsi direttamente con EventPipe tramite API come EventSource.WriteEvent o è possibile usare librerie che vi si basano, ad esempio OpenTelemetry. Il supporto di EventPipe consente anche agli strumenti di diagnostica .NET come dotnet-trace, dotnet-counters e dotnet-monitor di funzionare senza problemi con applicazioni Native AOT o CoreCLR. EventPipe è un componente facoltativo in Native AOT. Per includere il supporto di EventPipe, imposta la proprietà MSBuild EventSourceSupport su true.

<PropertyGroup>
    <EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>

Native AOT offre supporto parziale per alcuni provider di eventi noti. Non tutti gli eventi di runtime sono supportati in Native AOT.

Diagnostica in fase di sviluppo

Gli strumenti dell'interfaccia della riga di comando di .NET (SDK dotnet) e Visual Studio offrono comandi separati per build e publish. build (o Start in Visual Studio) usa CoreCLR. Solo publish crea un'applicazione Native AOT. La pubblicazione dell'app come Native AOT produce un'app compilata in anticipo (ahead-of-time, AOT) nel codice nativo. Come accennato in precedenza, non tutti gli strumenti di diagnostica funzionano perfettamente con le applicazioni Native AOT pubblicate in .NET 8. Tuttavia, tutti gli strumenti di diagnostica .NET sono disponibili per gli sviluppatori durante la fase di compilazione dell'applicazione. È consigliabile sviluppare, eseguire il debug e testare le applicazioni come di consueto e pubblicare l'app di lavoro con Native AOT solo in fase finale.

Debug nativo

Quando si esegue l'app durante lo sviluppo, ad esempio all'interno di Visual Studio, o con dotnet run, dotnet build o dotnet test, viene eseguita in CoreCLR per impostazione predefinita. Tuttavia, se PublishAot è presente nel file di progetto, il comportamento deve essere lo stesso in CoreCLR e Native AOT. Questa caratteristica ti consente di usare il motore di debug gestito standard di Visual Studio per lo sviluppo e il test.

Dopo la pubblicazione, le applicazioni Native AOT sono veri e propri file binari nativi. Il debugger gestito non funzionerà su di essi. Tuttavia, il compilatore Native AOT genera file eseguibili completamente nativi su cui i debugger nativi possono eseguire il debug nella piattaforma preferita, ad esempio WinDbg o Visual Studio in Windows e gdb o lldb nei sistemi di tipo Unix.

Il compilatore Native AOT genera informazioni su numeri di riga, tipi, variabili locali e parametri. Il debugger nativo ti consente di esaminare l'analisi dello stack e le variabili, di eseguire l'istruzione o il passaggio delle righe di origine o di impostare punti di interruzione di riga.

Per eseguire il debug di eccezioni gestite, imposta un punto di interruzione nel metodo RhThrowEx, che viene chiamato ogni volta che viene generata un'eccezione gestita. L'eccezione viene archiviata nel registro rcx o x0. Se il tuo debugger supporta la visualizzazione di oggetti C++, puoi eseguire il cast del registro in S_P_CoreLib_System_Exception* per visualizzare altre informazioni sull'eccezione.

La raccolta di un file dump per un'applicazione Native AOT prevede alcuni passaggi manuali in .NET 8.

Note specifiche di Visual Studio

Puoi avviare un eseguibile compilato da Native AOT nel debugger di Visual Studio aprendolo nell'IDE di Visual Studio. È necessario aprire il file eseguibile stesso in Visual Studio.

Per impostare un punto di interruzione che per ogni volta che viene generata un'eccezione, scegli l'opzione Punti di interruzione dal menu Debug > Windows. Nella nuova finestra, seleziona Nuova > Funzione punto di interruzione. Specifica RhThrowEx come Nome funzione e lascia l'opzione Linguaggio in Tutti i linguaggi (non selezionare C#).

Per visualizzare l'eccezione generata, avvia il debug (Debug > Avvia debug o F5), apri la finestra Espressioni di controllo (Debug > Windows > Espressioni di controllo) e aggiungi l'espressione seguente come una di quelle di controllo: (S_P_CoreLib_System_Exception*)@rcx. Questo meccanismo sfrutta il fatto che nel momento in cui RhThrowEx viene chiamato, il registro CPU x64 RCX contiene l'eccezione generata. Puoi anche incollare l'espressione nella finestra Immediata; la sintassi è identica a quella delle espressioni di controllo.

Importanza del file di simboli

Durante la pubblicazione, il compilatore Native AOT produce sia un file eseguibile che un file di simboli. Il debug nativo e le attività correlate, ad esempio la profilatura, richiedono l'accesso al file di simboli nativo. Se questo file non è presente,i risultati potrebbero essere compromessi o interrotti.

Per informazioni sul nome e sul percorso del file di simboli, vedi Informazioni di debug nativo.

Profilatura della CPU

È possibile usare strumenti specifici della piattaforma, ad esempio PerfView e Perf, per raccogliere esempi CPU di un'applicazione Native AOT.

Analisi dell'heap

L'analisi dell'heap gestito non è attualmente supportata in Native AOT. Gli strumenti di analisi dell’heap come dotnet-gcdump, PerfView e gli strumenti di analisi dell’heap di Visual Studio non funzionano in Native AOT in .NET 8.