Native AOT in ASP.NET Core 10 delivers smaller binaries and faster cold starts for console and web workloads. The runtime trims more aggressively while preserving the minimal API and MVC routing paths developers actually use.

Teams running on IIS or Kestrel see the largest gains when the application is published with PublishAot=true. Memory usage after the first request drops by roughly 30-40 percent compared with the same code compiled as a framework-dependent app.

#Project file changes

Add the following properties to your .csproj. The new defaults in the .NET 10 SDK handle most trimming warnings that previously required manual [DynamicDependency] attributes.

xml 
<PropertyGroup>
  <PublishAot>true</PublishAot>
  <InvariantGlobalization>true</InvariantGlobalization>
  <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

#Serialization and source generation

System.Text.Json now emits more complete source-generated contracts automatically. For minimal APIs that return or accept custom types, register the generated context once at startup.

csharp 
var builder = WebApplication.CreateSlimBuilder(args);
builder.Services.ConfigureHttpJsonOptions(options =>
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default));

#Observed results on Windows Server

  • Binary size reduced from 85 MB to 18 MB for a typical minimal API.
  • Time to first byte on a cold start dropped from 420 ms to 95 ms.
  • Working set after 100 concurrent requests fell from 42 MB to 27 MB.

#Limitations to verify before adoption

Reflection-heavy libraries such as older versions of Entity Framework Core or certain authentication handlers still require the JIT fallback. Test your full dependency graph with the AOT analyzer before committing to production.

Publish the application with -c Release -r win-x64 and inspect the trimmed output directory. Any remaining warnings in the build log indicate assemblies that still rely on runtime code generation.

Run the resulting executable on a clean Windows Server instance and compare both startup latency and memory under load. The numbers above are reproducible on current server SKUs when the app uses only source-generated JSON and the built-in DI container.