Publishing your app asNative AOT produces an app that'sself-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

The benefit of Native AOT is most significant for workloads with a high number of deployed instances, such as cloud infrastructure and hyper-scale services. .NET 8 addsASP.NET Core support for native AOT.

The Native AOT deployment model uses an ahead-of-time compiler to compile IL to native code at the time of publish. Native AOT apps don't use a just-in-time (JIT) compiler when the application runs. Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, such as Linux x64 or Windows x64, just like publishing aself-contained app.

Prerequisites

Publish Native AOT using the CLI

1. Add<PublishAot>true</PublishAot> to your project file.

   This property enables Native AOT compilation during publish. It also enables dynamic code-usage analysis during build and editing. It's preferable to put this setting in the project file rather than passing it on the command line, since it controls behaviors outside publish.

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

2. Publish the app for a specific runtime identifier usingdotnet publish -r <RID>.

   The following example publishes the app for Windows as a Native AOT application on a machine with the required prerequisites installed.

   dotnet publish -r win-x64 -c Release

   The following example publishes the app for Linux as a Native AOT application. A Native AOT binary produced on Linux machine is only going to work on same or newer Linux version. For example, Native AOT binary produced on Ubuntu 20.04 is going to run on Ubuntu 20.04 and later, but it isn't going to run on Ubuntu 18.04.

   dotnet publish -r linux-arm64 -c Release

The app is available in the publish directory and contains all the code needed to run in it, including a stripped-down version of the coreclr runtime.

Check out theNative AOT samples available in the dotnet/samples repository on GitHub. The samples includeLinux andWindows Dockerfiles that demonstrate how to automate installation of prerequisites and publish .NET projects with Native AOT using containers.

AOT-compatibility analyzers

TheIsAotCompatible property is used to indicate whether a library is compatible with Native AOT. Consider when a library sets theIsAotCompatible property totrue, for example:

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

The preceding configuration assigns a default oftrue to the following properties:

• IsTrimmable
• EnableTrimAnalyzer
• EnableSingleFileAnalyzer
• EnableAotAnalyzer

These analyzers help to ensure that a library is compatible with Native AOT.

Native debug information

By default, Native AOT publishing produces debug information in a separate file:

• Linux:.dbg
• Windows:.pdb
• macOS:.dSYM folder

The debug file is necessary for running the app under thedebugger or inspecting crash dumps. On Unix-like platforms, set theStripSymbols property tofalse to include the debug information in the native binary. Including debug information makes the native binary larger.

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

Limitations of Native AOT deployment

Native AOT apps have the following limitations:

• No dynamic loading, for example,Assembly.LoadFile.
• No run-time code generation, for example,System.Reflection.Emit.
• No C++/CLI.
• Windows: No built-in COM.
• Requires trimming, which haslimitations.
• Implies compilation into a single file, which has knownincompatibilities.
• Apps include required runtime libraries (just likeself-contained apps, increasing their size as compared to framework-dependent apps).
• System.Linq.Expressions always use their interpreted form, which is slower than run-time generated compiled code.
• Generic parameters substituted with struct type arguments will have specialized code generated for each instantiation. In the dynamic runtime, many instantiations are generated on-demand. In Native AOT, all instantiations are pre-generated. This can have significant impact to the disk size of the application. Generic virtual methods and generic instance methods will also have an instantiation for every implementing or overriding type.
• Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.
• Diagnostic support for debugging and profiling with some limitations.
• Support for some ASP.NET Core features. For more information, seeASP.NET Core support for Native AOT.

The publish process analyzes the entire project and its dependencies for possible limitations. Warnings are issued for each limitation the published app might encounter at run time.

Platform/architecture restrictions

The following table shows supported compilation targets.

For more information about how specific platform is supported with Native AOT, follow the link from the table.