Diagnóstico e instrumentación

AOT nativo comparte algunas funcionalidades de diagnóstico e instrumentación, pero no todas, con CoreCLR. Debido a la amplia selección de utilidades de diagnóstico de CoreCLR, a veces es adecuado diagnosticar y depurar problemas en CoreCLR. Las aplicaciones compatibles con el recorte no deben tener diferencias de comportamiento, por lo que las investigaciones a menudo se aplican a ambos entornos de ejecución. Sin embargo, solo se puede recopilar información después de la publicación, por lo que AOT nativo también proporciona herramientas de diagnóstico posteriores a la publicación.

Compatibilidad con el diagnóstico de AOT nativo de .NET 8

En la tabla siguiente se resumen las características de diagnóstico admitidas para las implementaciones nativas de AOT:

Característica	Totalmente compatible	Compatibilidad parcial	No compatible
Observabilidad y telemetría		✔️Compatibilidad parcial
Diagnósticos en tiempo de desarrollo	✔️Compatibilidad total
Depuración nativa		✔️Compatibilidad parcial
Generación de perfiles de CPU		✔️Compatibilidad parcial
Análisis por montón			❌No compatible

Observabilidad y telemetría

A partir de .NET 8, el entorno de ejecución de AOT nativo admite EventPipe, que es la capa base que usan muchas bibliotecas de registro y seguimiento. Puede interactuar con EventPipe directamente a través de API como EventSource.WriteEvent o puede usar bibliotecas integradas en la parte superior, como OpenTelemetry. La compatibilidad con EventPipe también permite que herramientas de diagnóstico .NET como dotnet-trace, dotnet-counters y dotnet-monitor funcionen sin problemas con aplicaciones AOT nativas o CoreCLR. EventPipe es un componente opcional en AOT nativo. Para incluir compatibilidad con EventPipe, establezca la propiedad EventSourceSupport MSBuild en true.

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

AOT nativo proporciona compatibilidad parcial con algunos proveedores de eventos conocidos. No todos los eventos en runtime se admiten en AOT nativo.

Diagnósticos en tiempo de desarrollo

Las herramientas de la CLI de .NET (dotnet SDK) y Visual Studio ofrecen comandos independientes para build y publish. build (o Start en Visual Studio) usa CoreCLR. Solo publish crea una aplicación AOT nativa. La publicación de la aplicación como AOT nativa genera una aplicación que se ha compilado con antelación (AOT) en código nativo. Como se mencionó anteriormente, no todas las herramientas de diagnóstico funcionan sin problemas con las aplicaciones AOT nativas publicadas en .NET 8. Sin embargo, todas las herramientas de diagnóstico de .NET están disponibles para los desarrolladores durante la fase de creación de aplicaciones. Se recomienda desarrollar, depurar y probar las aplicaciones como de costumbre y publicar la aplicación de trabajo con AOT nativo como uno de los últimos pasos.

Depuración nativa

Al ejecutar la aplicación durante el desarrollo, como en Visual Studio, o con dotnet run, dotnet buildo dotnet test, se ejecuta en CoreCLR de forma predeterminada. Sin embargo, si PublishAot está presente en el archivo de proyecto, el comportamiento debe ser el mismo entre CoreCLR y AOT nativo. Esta característica le permite usar el motor de depuración administrado estándar de Visual Studio para desarrollo y pruebas.

Después de la publicación, las aplicaciones AOT nativas son archivos binarios nativos verdaderos. El depurador administrado no funcionará en ellos. Sin embargo, el compilador AOT nativo genera archivos ejecutables totalmente nativos que los depuradores nativos pueden depurar en la plataforma que prefiera (por ejemplo, WinDbg o Visual Studio en Windows y gdb o lldb en sistemas similares a Unix).

El compilador AOT nativo genera información sobre números de línea, tipos, variables locales y parámetros. El depurador nativo le permite inspeccionar el seguimiento de la pila y las variables, pasar por las líneas de origen o establecer puntos de interrupción de línea.

Para depurar excepciones administradas, establezca un punto de interrupción en el RhThrowEx método, al que se llama cada vez que se produce una excepción administrada. La excepción se almacena en el rcx registro o x0. Si el depurador admite la visualización de objetos de C++, puede convertir el registro en S_P_CoreLib_System_Exception* para ver más información sobre la excepción.

La recopilación de un archivo de volcado de memoria para una aplicación AOT nativa implica algunos pasos manuales en .NET 8.

Notas específicas de Visual Studio

Puede iniciar un archivo ejecutable compilado con AOT nativo en el depurador de Visual Studio abriendolo en el IDE de Visual Studio. Debe abrir el archivo ejecutable en Visual Studio.

Para establecer un punto de interrupción que se interrumpa cada vez que se produzca una excepción, elija la opción Puntos de interrupción en el menú Depurar > Windows. En la nueva ventana, seleccione Nuevo > punto de interrupción de función. Especifique RhThrowEx como nombre de función y deje la opción Idioma en Todos los lenguajes (no seleccione C#).

Para ver qué excepción se produjo, inicie la depuración (Depurar > Iniciar depuración o F5), abra la ventana Inspección (Depurar > Inspección de Windows >)y agregue la siguiente expresión como uno de los relojes: (S_P_CoreLib_System_Exception*)@rcx. Este mecanismo aprovecha el hecho de que, en el momento RhThrowEx en que se llama, el registro de CPU x64 RCX contiene la excepción iniciada. También puede pegar la expresión en la ventana Inmediato; la sintaxis es la misma que para los relojes.

Importancia del archivo de símbolos

Al publicar, el compilador AOT nativo genera un archivo ejecutable y un archivo de símbolos. La depuración nativa y las actividades relacionadas, como la generación de perfiles, requieren acceso al archivo de símbolos nativo. Si este archivo no está presente, es posible que haya degradado o roto los resultados.

Para obtener información sobre el nombre y la ubicación del archivo de símbolos, vea Información de depuraciónnativa.

Generación de perfiles de CPU

Las herramientas específicas de la plataforma, como PerfView y Perf, se pueden usar para recopilar ejemplos de CPU de una aplicación AOT nativa.

Análisis del montón

El análisis de montón administrado no se admite actualmente en AOT nativo. Las herramientas de análisis de montón como dotnet-gcdump, PerfView y las herramientas de análisis del montón de Visual Studio no funcionan en AOT nativo en .NET 8.