.NET › CI/CD, Publishing & Deployment

What is Native AOT compilation in .NET, and what are its main benefits and limitations?

Advanced

Answer

Native AOT (Ahead-of-Time) compilation compiles a .NET application directly into a self-contained native executable at build time, rather than compiling to intermediate language and relying on the JIT compiler at runtime -- this produces faster startup (no JIT warmup), lower memory usage (no JIT infrastructure needed at runtime), and a smaller, single-file deployment artifact. The main trade-off is that because everything must be resolvable at compile time, dynamic features like full reflection are only partially supported, which can break libraries (particularly some serializers) that rely heavily on runtime type inspection -- Native AOT suits microservices, serverless functions, and CLI tools where fast, predictable startup matters most.
<!-- Enabling Native AOT in a .csproj is a single property -->
<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

# dotnet publish -r linux-x64 -c Release --self-contained
# produces a single native executable, no separate .NET runtime install needed on the target machine
Real-world example A serverless function billed by execution time and cold-start latency is republished with Native AOT enabled, eliminating JIT warmup entirely and meaningfully reducing the function's average cold-start time compared to the standard JIT-compiled deployment.

Common follow-ups: What specific JSON serialization approach is compatible with Native AOT's reflection limitations?;How do you validate that a given third-party library actually supports Native AOT before adopting it?