Развертывание AOT в родной среде

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

Преимущество нативного AOT является наиболее значительным для рабочих нагрузок с большим количеством развернутых экземпляров, таких как облачная инфраструктура и гипермасштабные службы. .NET 8 добавляет поддержку ASP.NET Core для нативнойAOT.

Нативная модель развертывания AOT использует компилятор предварительной компиляции для компиляции IL в машинный код при публикации. Собственные приложения AOT не используют JIT-компилятор при запуске приложения. Собственные приложения AOT могут выполняться в ограниченных средах, где JIT не разрешен. Собственные приложения AOT предназначены для конкретной среды выполнения, например Linux x64 или Windows x64, так же, как публикация автономного приложения.

Предпосылки

Публикация нативного AOT с помощью командной строки

1. Добавьте <PublishAot>true</PublishAot> в файл проекта.

   Это свойство обеспечивает возможность независимой от среды выполнения AOT-компиляции во время развертывания. Он также включает динамический анализ использования кода во время сборки и редактирования. Предпочтительнее поместить этот параметр в файл проекта, а не передать его в командной строке, так как он управляет поведением вне публикации.

   <PropertyGroup>
       <PublishAot>true</PublishAot>
   </PropertyGroup>
   

2. Опубликуйте приложение для определенного идентификатора среды выполнения с помощью dotnet publish -r <RID>.

   В следующем примере приложение для Windows публикуется как собственное приложение AOT на компьютере с установленными необходимыми предварительными требованиями.

   dotnet publish -r win-x64 -c Release

   В следующем примере приложение для Linux развертывается как нативное приложение AOT. Собственный двоичный файл AOT, созданный на компьютере Linux, будет работать только в той же или более новой версии Linux. Например, двоичный файл Native AOT, созданный в Ubuntu 20.04, будет работать в Ubuntu 20.04 и более поздних версиях, но он не будет работать в Ubuntu 18.04.

   dotnet publish -r linux-arm64 -c Release

Приложение доступно в каталоге публикации и содержит весь код, необходимый для его выполнения, включая упрощённую версию среды выполнения CoreCLR.

Ознакомьтесь с примерами Native AOT, доступными в репозитории dotnet/samples на сайте GitHub. Примеры включают Linux и Windows Dockerfiles, демонстрирующие, как автоматизировать установку необходимых компонентов и публиковать проекты .NET с Native AOT, используя контейнеры.

Анализаторы совместимости AOT

Свойство IsAotCompatible используется для указания, совместима ли библиотека с Native AOT. Рассмотрим, когда библиотека задает свойству IsAotCompatible значение true, например:

<PropertyGroup>
    <IsAotCompatible>true</IsAotCompatible>
</PropertyGroup>

Предыдущая конфигурация назначает значение по умолчанию true следующим свойствам:

• IsTrimmable
• EnableTrimAnalyzer
• EnableSingleFileAnalyzer
• EnableAotAnalyzer

Эти анализаторы помогают обеспечить совместимость библиотеки с Native AOT.

Встроенные сведения об отладке

По умолчанию нативная публикация AOT создает сведения об отладке в дополнительном файле:

• Linux: .dbg
• Windows: PDB
• macOS: папка .dSYM

Файл отладки необходим для запуска приложения с отладчиком или проверки дампов с ошибками. На платформах Unix задайте свойству StripSymbols значение false, чтобы включить сведения отладки в нативный двоичный файл. Включение сведений об отладке делает собственный двоичный файл большим.

<PropertyGroup>
    <StripSymbols>false</StripSymbols>
</PropertyGroup>

Ограничения развертывания нативного AOT

Собственные приложения AOT имеют следующие ограничения:

• Нет динамической загрузки, например, Assembly.LoadFile.
• Отсутствие создания кода во время выполнения, например, System.Reflection.Emit.
• Нет C++/CLI.
• Windows: нет встроенного COM.
• Требуется обрезка, которая имеет ограничения .
• Компиляция в один файл подразумевает наличие известных несовместимостей и.
• Приложения включают в себя необходимые библиотеки среды выполнения (так же, как и автономные приложения), что увеличивает их размер по сравнению с приложениями, зависящими от фреймворка.
• System.Linq.Expressions всегда используют интерпретируемую форму, которая медленнее, чем скомпилированный код, создаваемый во время выполнения.
• Универсальные параметры, замененные аргументами типа структуры, будут иметь специализированный код, созданный для каждого экземпляра. В динамической среде выполнения создается множество экземпляров по запросу. В собственном Native AOT все инстанции создаются заранее. Это может существенно повлиять на размер диска приложения. Универсальные виртуальные методы и универсальные методы экземпляра также будут иметь инстанцирование для каждого реализующего или переопределяющего типа.
• Не все библиотеки среды выполнения полностью аннотированы для совместимости с Native AOT. То есть некоторые предупреждения в библиотеках среды выполнения не могут быть устранены конечными разработчиками.
• Диагностическую поддержку для отладки и профилирования с некоторыми ограничениями.
• Поддержка некоторых функций ASP.NET Core. Дополнительные сведения см. в поддержке ASP.NET Core для независимогоAOT.

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

Ограничения платформы и архитектуры

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

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