With the arrival of .NET 8, Microsoft introduced more robust support for Native AOT (Ahead-of-Time) compilation across the .NET ecosystem. Native AOT promises faster startup, smaller memory footprint, and a self-contained binary that does not require JIT compilation at runtime. But as you might expect, not all application types and frameworks are fully compatible with Native AOT out of the box.
One frequent question is: Does ASP.NET Core MVC support Native AOT? In this article, we’ll walk through what the current reality is, why it’s limited, and what alternatives or workarounds are available.
What Is Native AOT, and Why Use It?
Native AOT is a publishing mode where your application’s Intermediate Language (IL) is compiled ahead of time into native machine code. That means there's no JIT compilation at runtime, which can reduce startup latency, shrink memory overhead, and simplify deployment (because the resulting binary includes everything needed to run, no separate runtime dependency).
These advantages are particularly compelling for:
- Short-lived applications, serverless functions, or microservices that spin up frequently
- Situations where startup latency matters
- Environments where JIT is restricted or undesirable
However, Native AOT demands stricter constraints on what dynamic or reflection-based features your code (and libraries) employ.
Current Status: What ASP.NET Core Supports with Native AOT
As of .NET 8 and present previews, Microsoft has enabled Native AOT support for certain ASP.NET Core scenarios, with notable caveats and limitations.
What is supported
- Minimal APIs are supported under Native AOT.
- gRPC service apps are supported.
- Worker services (non-HTTP background services) are supported.
Because these scenarios tend to use less dynamic reflection and more static configuration, they match better with AOT’s constraints.
What isn’t supported (or only partially)
- MVC (controllers, views, filters, Razor Pages) — these rely heavily on reflection, runtime model binding, dynamic features, and runtime view compilation, making full AOT compatibility difficult.
- Features built atop MVC, such as Razor views, view compilation, TagHelpers, dynamic model binding, are typically not fully supported in Native AOT mode.
- Blazor Server, SignalR, Session state, many advanced authentication types, etc., also face compatibility problems under Native AOT.
Thus, in the built-in Microsoft documentation, MVC is marked among the features that are not yet supported under Native AOT in full.
In fact, there’s an open issue in the ASP.NET Core repository exploring “Native AOT support for MVC.” That indicates the team considers MVC support a future possibility, but it’s not ready today.
Because of these limitations, the official ASP.NET Core templates for Native AOT (for example, the webapiaot template) are built around Minimal APIs and omit MVC by design.
Why MVC is Challenging for Native AOT
Several reasons make MVC a poor fit (so far) for Native AOT:
Heavy reliance on runtime reflection
MVC’s model binding, action invocation, controller discovery, filters, routing, and DI resolution often use reflection, which is harder to analyze statically in an AOT context.
Dynamic type usage and code paths
MVC apps sometimes rely on runtime code paths—for example, building expressions, dynamically accessing properties, or using Type.GetType(...) or Activator.CreateInstance(...)—which Native AOT must account for via hints or trimming, making correctness harder to guarantee.
Razor view compilation at runtime
Views (Razor cshtml) are often compiled or interpreted at runtime, which conflicts with pure ahead-of-time compilation. Precompiling views helps, but even so there are dynamic behaviors that may be hard to capture.
Third-party dependencies
Many MVC-related NuGet packages expect full runtime flexibility, which may break under AOT’s constraints.
Because of these reasons, enabling MVC in a Native AOT app may result in runtime errors (missing methods, reflection failures, trimming issues) or features being disabled.
What Happens If You Try to Use MVC with Native AOT
If you attempt to enable PublishAot = true on a standard MVC-based ASP.NET Core app, one or more of these can occur:
- Build-time warnings or errors indicating unsupported usage (reflection not analyzable)
- Runtime failures, such as missing methods, type load exceptions, or parts of the MVC pipeline not executing
- Some MVC features simply disabled or throwing “not supported in AOT” exceptions
Therefore, it's not currently recommended to convert a full MVC-based web app into a Native AOT app without extensive refactoring and testing.
How to Enable Native AOT (for Supported Scenarios)
In projects where Native AOT is supported (Minimal APIs, gRPC, worker apps), you can enable it as follows:
1. In your .csproj, add:
<PropertyGroup>
<PublishAot>true</PublishAot>
</PropertyGroup>2. Then publish the app (e.g. via dotnet publish -c Release) — during this process the compiler will perform static analysis and trim unused code, and produce a native executable.
3. You should review any warnings issued about trimming or compatibility, and thoroughly test the published binary.
Note: Native AOT compilation happens only during publish; local dotnet run or debugging still uses the usual JIT pipeline.
Also, for ASP.NET Core web apps, Microsoft provides a specialized template named webapiaot that builds a minimal API–style project configured for AOT. This template intentionally excludes MVC components by default.
Alternatives & Workarounds
Given that MVC support is not ready for Native AOT, here are some strategies to adopt:
Switch to Minimal APIs where feasible
If your app’s endpoints are relatively simple, migrating controllers to Minimal API style may allow you to benefit from Native AOT.
Hybrid architecture
Use a minimal-AOT service for performance-sensitive paths, and host MVC components in a separate standard JIT-deployed app.
Partial AOT / trimming without Native AOT
You may use trimming (IL trimming) in a non-AOT publish, which can reduce footprint and remove unused code, while still using JIT. This gives some of the size benefits without requiring full AOT compatibility.
Wait for future support
Keep an eye on GitHub issues and .NET roadmap announcements; full AOT support for MVC remains a requested feature and may arrive in future .NET versions.
When Should You Consider Native AOT for Web Apps?
Native AOT is compelling when:
- Your application is restarted frequently (serverless, container startup)
- Startup latency is a key KPI
- You deploy many instances where memory and binary size optimizations yield large cumulative gains
- Your application logic does not heavily depend on dynamic or reflection-based features
But if you have a classic, rich MVC app with views, filters, dynamic features, hybrid client-server state, and so on, the benefit-risk tradeoff may not favor trying Native AOT at present.
Conclusion
To answer the question succinctly:
No — ASP.NET Core MVC is not yet fully supported under Native AOT in .NET 8. The heavy dependence of MVC on runtime reflection, dynamic behavior, view compilation, and dependencies makes full compatibility difficult today.
That said, Microsoft and the .NET team are working toward improving AOT support across more web frameworks. In the meantime, you can leverage Native AOT with Minimal API–based applications, gRPC, and other simpler scenarios, while continuing to use MVC in a conventional JIT environment.