# Overview
.NET 7 introduced [support for publishing .NET console projects as… _native AOT_](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/), producing a self-contained, platform-specific executable without any runtime JIT. Native AOT apps start up very quickly and use less memory. The application can be deployed to a machine or container that doesn't have any .NET runtime installed. In .NET 8 we will extend support for native AOT to ASP.NET Core, starting with cloud-focused, API applications built with Minimal APIs that meet expectations regarding published file size, startup time, working set, and throughput performance.
# Scope
As stated, the primary focus for .NET 8 will be on enabling native AOT publish of ASP.NET Core API applications using Minimal APIs. "Support native AOT" in this context means ensuring that projects can enable native AOT publish via the `<PublishAOT>` project property and the resulting development experience leads developers to producing native AOT published applications without build, publish, or runtime warnings and errors. This means that the majority of foundational feature areas of ASP.NET Core and .NET will need to be updated to support native AOT, including:
- Hosting APIs including `WebApplication`, etc.
- Kestrel HTTP server
- Configuration & Options
- Logging
- Dependency injection
- Common middleware
- Authentication and Authorization
- Minimal APIs
- Health Checks
- Data access with ADO.NET (SQLite and PostgreSQL as the primary targets)
- OpenAPI support
- Observability and diagnostics
Additionally, as a secondary goal, we will make progress towards enabling native AOT publish for the following feature areas:
- gRPC
- SignalR
- MVC Web APIs
- Entity Framework
The following feature areas are out of scope for native AOT support for now:
- MVC views and Razor Pages
- Blazor Server
## Development experience principles
Native AOT has limitations that mean certain APIs and code patterns in .NET are not supported when publishing native AOT. These include features that rely on runtime JIT, e.g. dynamic code generation and compilation, assembly loading, etc., as well as patterns that result in code being trimmed away by the native AOT compilation process that is needed to execute the application, resulting in runtime failures.
In adding support to ASP.NET Core for native AOT, we must ensure that the development experience is such that developers can reasonably determine how their app will run once published as native AOT. Where current APIs and features are designed in such a way that are incompatible with native AOT, we will utilize tools including source generators, analyzers, and code fixers, to allow existing APIs to work with native AOT or for developers to update their apps to work with native AOT in a reasonable fashion.
# Stages
## Stage 1
Stage 1 of this effort will be to enable creation of ASP.NET Core API projects using a [new project template](#45526), enabled for native AOT, that can be built, published, and run without any warnings or errors, and that meets the defined metric targets for executable file size, startup time, working set, and throughput.
### Metric Targets
These are primarily Linux-focused as that's the primary deployment target, but size on Windows on macOS will still be tracked and kept in line with these targets as it often contributes to perception during candidate platform investigations.
- 10 MB executable file size
- <50 ms startup time (ready to accept first request)
- <50 MB working set memory footprint (ready to accept first request)
- <50 MB working set memory footprint (after handling load test)
- Within 5% of default CoreCLR RPS on Citrine perf environment
- *"default" here means compared to the default configuration of a CoreCLR-based deployment of the app, e.g. including tiered JIT*
## Stage 2
Stage 2 builds on stage 1 to enable more "real-world" ASP.NET Core API applications to be native AOT published. These applications will use more features typically associated with running API applications in cloud environments including AuthN/Z, data access, OpenTelemetry, etc. The [TrimmedTodo API application](https://github.com/DamianEdwards/TrimmedTodo) will serve as the initial example of this kind of application.
### Stage 2.a
Feature areas to be made compatible with native AOT in stage 2.a as part of .NET 8:
1. Configuration & Options inc. binding and validation
- [x] https://github.com/dotnet/runtime/issues/44493
- [x] https://github.com/dotnet/runtime/issues/85475
2. Data access via ADO.NET using the Npgsql provider (for PostgreSQL) and, as a secondary priority, Sqlite
- [ ] https://github.com/npgsql/npgsql/issues/4764
3. Authentication, using the JWT handler, and Authorization using existing ASP.NET Core authorization features
- [x] https://github.com/dotnet/aspnetcore/issues/47487
5. Health Checks, with a primary focus on the in-framework providers and cloud native deployed scenarios, e.g. readiness & health probes
6. Open Telemetry,
- [x] https://github.com/open-telemetry/opentelemetry-dotnet/issues/3429
#### Metric Targets
These are primarily Linux-focused as that's the primary deployment target, but size on Windows on macOS will still be tracked and kept in line with these targets as it often contributes to perception during candidate platform investigations.
- 20 MB executable file size
- <150 ms startup time (ready to accept first request)
- <60 MB working set memory footprint (ready to accept first request)
- <60 MB working set memory footprint (after handling load test)
- Within 5% of default CoreCLR RPS on Citrine perf environment
- *"default" here means compared to the default configuration of a CoreCLR-based deployment of the app, e.g. including tiered JIT*
### Stage 2.b
Feature areas to be made compatible with native AOT in stage 2.b, likely beyond .NET 8. Note that work towards native AOT compatibility for these areas will likely begin in .NET 8, but not be completed:
1. OpenAPI/Swagger
2. Validation of minimal API arguments
- This is a new feature area for .NET 8 that if delivered should be made native AOT friendly
4. SignalR
6. MVC Web APIs
