Data Layer at Scale — series:
EF Core 10 AOT: what's broken (this article)
Dapper.AOT broken on .NET 10 (link TBD)
Extern alias benchmarking (link TBD)
Cold start vs density (link TBD)
Allocation numbers for k8s (link TBD)
The benchmark lied (link TBD)
The data layer as a line item (link TBD)
Measure, then migrate (link TBD)
The Short Answer
EF Core 10's NativeAOT support is officially marked experimental, not for production. Having validated this hands-on — by restructuring a real data layer until every documented constraint was satisfied — I can confirm: the label is accurate, and the failure mode is harder than you'd expect.
This article documents the three bugs that block production use, where workarounds exist, and what to use instead today.
The Intended Path
Microsoft's documented approach to EF Core AOT is precompiled queries via the dotnet ef CLI:
dotnet ef dbcontext optimize --precompile-queries --nativeaotThis generates a static compiled model and precompiled query interceptors that replace runtime LINQ translation. The goal: no expression trees, no Roslyn at runtime, no AOT violations.
In principle, clean. In practice, three bugs stop you.
Bug 1: Any Indirection Is "Dynamic LINQ" (efcore#32727)
The precompiler classifies a LINQ query as "Dynamic LINQ" — and rejects it — if the DbSet is accessed through any abstraction: an extension method, a generic wrapper, or an abstract base class.
This fails at precompile time:
// Extension method wrapping the set
public static IQueryable<Order> ActiveOrders(this AppDbContext db)
=> db.Orders.Where(o => !o.IsDeleted);
// Using it
var results = await _db.ActiveOrders().ToListAsync();This also fails:
// Generic repository base
public abstract class RepositoryBase<T> where T : class
{
protected abstract DbSet<T> GetSet();
public IQueryable<T> All() => GetSet();
}The only accepted form:
// Direct property access, no indirection
var results = await _db.Orders
.Where(o => !o.IsDeleted)
.ToListAsync();Every query must reference the DbSet property directly on the concrete DbContext type. This eliminates virtually all real-world repository patterns — and any framework that routes queries through a generic seam.
Bug 2: DbContext as Field or Parameter (efcore#35887)
Even with direct DbSet access, the precompiler misclassifies the context when it's reached through a field or a captured constructor parameter.
Fails:
public class OrderService(AppDbContext db)
{
public async Task<Order?> GetByIdAsync(int id)
=> await db.Orders.FindAsync(id); // captured primary-ctor parameter
}Workaround — copy to a local variable first:
public async Task<Order?> GetByIdAsync(int id)
{
var local = _db; // local copy
return await local.Orders.FindAsync(id);
}Awkward but functional. It satisfies the precompiler's symbol analysis. Add it to every method that queries the database.
Bug 3: Parameterized Queries Throw UnreachableException (Blocking, No Workaround)
This is the blocker. After restructuring an entire data layer to satisfy bugs 1 and 2 — direct DbSet access, local-variable copies, even the exact doc-prescribed shape (a static method taking the context as its first parameter, one expression rooted in db.<DbSet>) — the precompiler throws:
System.Diagnostics.UnreachableException: IdentifierName of type ParameterSymbolThis exception fires on every query with a parameter: an id, a CancellationToken, a max-count limit. Parameterless queries precompile cleanly. Any query that touches a method parameter does not.
There is no configuration to disable this. There is no workaround. (Related trail: dotnet/efcore#35494.)
Example of a query that triggers it:
public static Task<Order?> GetById(AppDbContext db, int id, CancellationToken ct)
=> db.Orders
.Where(o => o.Id == id) // 'id' is a ParameterSymbol — crashes the precompiler
.FirstOrDefaultAsync(ct);The same code under JIT — no precompile step — works perfectly.
Join the conversation! Your thoughts help the community grow.