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

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

Поддержка диагностики AOT в машинном коде

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

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

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

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

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

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

Диагностика во время разработки

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

Нативная отладка

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

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

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

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

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

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

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

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

Чтобы узнать, какое исключение было выброшено, начните отладку (Запуск > отладки или F5) и когда RhThrowEx точка останова сработает, откройте окно наблюдения (Отладка > Windows > Наблюдение) и добавьте следующее выражение в качестве одного из наблюдений:

Архитектура	Выражение
Архитектура x64	(S_P_CoreLib_System_Exception*)@rcx
Архитектура Arm64	(S_P_CoreLib_System_Exception*)@x0

Этот механизм использует тот факт, что в момент вызова RhThrowEx, в таблице указывается, что регистр ЦП содержит сгенерированное исключение. Вы также можете вставить выражение в окно интерпретации Visual Studio; Синтаксис совпадает с синтаксисом для часов.

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

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

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

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

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

Анализ кучи

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

См. также

• Встроенная поддержка диагностики AOT в iOS и Mac Catalyst