Диагностика и инструментирование

Собственный AOT использует некоторые, но не все, диагностика и возможности инструментирования с CoreCLR. Благодаря богатому выбору служебных программ диагностики CoreCLR иногда целесообразно диагностировать и отлаживать проблемы в CoreCLR. Приложения, совместимые с обрезкой , не должны иметь различий в поведении, поэтому исследования часто применяются к обеим средам выполнения. Тем не менее, некоторые сведения можно собирать только после публикации, поэтому Native AOT также предоставляет средства диагностики после публикации.

Поддержка диагностики .NET 8 Native AOT

В следующей таблице приведены сведения о функциях диагностики, поддерживаемых для развертываний Машинного развертывания AOT:

Функция	полностью поддерживается.	Частично поддерживается	Не поддерживается
Наблюдаемость и телеметрия		✔️Частично поддерживается
Время разработки диагностика	✔️Полностью поддерживается
Собственная отладка		✔️Частично поддерживается
Профилирование ЦП		✔️Частично поддерживается
Анализ кучи			❌Не поддерживаются

Наблюдаемость и телеметрия

По состоянию на .NET 8 среда выполнения Native AOT поддерживает EventPipe, который является базовым уровнем, используемым многими библиотеками ведения журнала и трассировки. Вы можете использовать EventPipe напрямую через API EventSource.WriteEvent или использовать библиотеки, созданные на основе OpenTelemetry. Поддержка EventPipe также позволяет средствам диагностики .NET, таким как dotnet-trace, dotnet-counters и dotnet-monitor , легко работать с приложениями Native AOT или CoreCLR. EventPipe является необязательным компонентом в машинном AOT. Чтобы включить поддержку EventPipe, задайте EventSourceSupport для свойства MSBuild значение true.

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

Собственный AOT обеспечивает частичную поддержку некоторых известных поставщиков событий. Не все события среды выполнения поддерживаются в машинном AOT.

Время разработки диагностика

Средства .NET CLI (dotnet SDK) и Visual Studio предлагают отдельные команды для build и publish. build (или Start в Visual Studio) использует CoreCLR. Создает только publish собственное приложение AOT. Публикация приложения как Native AOT создает приложение, скомпилированное в машинном коде. Как упоминание ранее, не все средства диагностики легко работают с опубликованными приложениями AOT в .NET 8. Однако все средства диагностики .NET доступны разработчикам на этапе создания приложения. Рекомендуется разрабатывать, отлаживать и тестировать приложения как обычно и публиковать рабочее приложение с машинным AOT в качестве одного из последних шагов.

Собственная отладка

При запуске приложения во время разработки, например в Visual Studio или с dotnet rundotnet build,или dotnet testв CoreCLR, он выполняется по умолчанию. Однако, если PublishAot он присутствует в файле проекта, поведение должно быть одинаковым между CoreCLR и Native AOT. Эта характеристика позволяет использовать стандартный модуль управляемой отладки Visual Studio для разработки и тестирования.

После публикации собственные приложения AOT являются собственными двоичными файлами. Управляемый отладчик не будет работать над ними. Однако компилятор AOT native AOT создает полностью собственные исполняемые файлы, которые собственные отладчики могут выполнять отладку на выбранной платформе (например, WinDbg или Visual Studio в Windows и gdb или lldb в системах, таких как Unix).

Собственный компилятор AOT создает сведения о номерах строк, типах, локальных и параметрах. Собственный отладчик позволяет проверять трассировку и переменные стека, переходить в исходные строки или задавать точки останова.

Чтобы выполнить отладку управляемых исключений, задайте точку останова для RhThrowEx метода, которая вызывается всякий раз, когда возникает управляемое исключение. Исключение хранится в или x0 регистреrcx. Если отладчик поддерживает просмотр объектов C++, можно привести регистр, чтобы S_P_CoreLib_System_Exception* просмотреть дополнительные сведения об исключении.

Сбор файла дампа для собственного приложения AOT включает в себя некоторые действия вручную в .NET 8.

Заметки, относящиеся к Visual Studio

Вы можете запустить исполняемый файл, скомпилированный в машинном коде AOT, в отладчике Visual Studio, открыв его в интегрированной среде разработки Visual Studio. Необходимо открыть исполняемый файл в Visual Studio.

Чтобы задать точку останова, которая прерывается всякий раз при возникновении исключения, выберите параметр точек останова в меню Отладки > Windows . В новом окне выберите "Новая > точка останова функции ". Укажите RhThrowEx имя функции и оставьте параметр "Язык" на всех языках (не выбирайте C#).

Чтобы узнать, какое исключение было создано, запустите отладку (отладка запуска отладки или F5), откройте окно "Просмотр" (отладочная >> проверка Windows>) и добавьте следующее выражение в качестве одного из часов: (S_P_CoreLib_System_Exception*)@rcx Этот механизм использует тот факт, что во время RhThrowEx вызова регистр ЦП x64 содержит исключение. Можно также вставить выражение в окно Интерпретации; Синтаксис совпадает с синтаксисом для часов.

Важность файла символов

При публикации собственный компилятор AOT создает исполняемый файл и файл символов. Для отладки в машинной среде и связанных действий, таких как профилирование, требуется доступ к собственному файлу символов. Если этот файл отсутствует, возможно, у вас будут нарушены или нарушены результаты.

Сведения о имени и расположении файла символов см. в сведениях об отладке в машинной среде.

Профилирование ЦП

Средства для конкретной платформы, такие как PerfView и Perf , можно использовать для сбора примеров ЦП собственного приложения AOT.

Анализ кучи

Анализ управляемой кучи в настоящее время не поддерживается в машинном AOT. Средства анализа кучи, такие как dotnet-gcdump, PerfView и средства анализа кучи Visual Studio, не работают в машинном AOT в .NET 8.