.NET 11 ships: faster AOT, smaller containers, three-year LTS

What happened

Microsoft shipped .NET 11 on November 11, 2026, and tagged it as a Long-Term Support release — three years of patches, security fixes, and runtime updates through November 2028. It's the successor to .NET 10 (STS, one year of support) and the natural landing spot for anyone still on the .NET 8 LTS track, which runs out of support next year.

The release bundles the usual stack: the .NET 11 runtime, C# 14, F# 10, ASP.NET Core 11, EF Core 11, MAUI, and the SDK. The headline themes are the same ones Microsoft has been grinding on for three releases now — Native AOT, container size, startup time, and closing the last gaps where AOT still falls back to reflection or JIT.

The practical story isn't a single marquee feature; it's that AOT has quietly crossed the line from 'interesting experiment' to 'default choice for new services.' ASP.NET Core minimal APIs, gRPC, and most of the BCL now compile cleanly under `PublishAot=true`, and the generated binaries are smaller and start faster than the .NET 10 equivalents. Microsoft is reporting double-digit percentage improvements in cold-start latency for typical web workloads, with container images that land in the tens of megabytes rather than the hundreds.

Why it matters

For most teams, the interesting question isn't 'what's new in .NET 11' — it's 'can we finally retire .NET Framework / .NET 8 without regressions.' The answer this cycle is yes, with asterisks.

The AOT story is the one that actually changes deployment math. A .NET service that used to ship as a 200MB container with a one-second cold start is now a 40MB container with a sub-200ms cold start. That's not a marketing number — it's the difference between .NET being a viable Lambda / Cloud Run / Fly.io target and being the thing you reach for only when you're already on Azure App Service. Go and Rust have had this profile for years; .NET is now in the same neighborhood, and the serverless cost math changes accordingly.

C# 14 is a quieter release than C# 12 or 13 were. Extension members (properties and static methods on top of the existing extension method support) are the biggest syntactic addition, and they land cleanly — the feature has been cooking in previews for two cycles. Field-backed properties get a `field` keyword that removes a whole category of boilerplate. Nothing earth-shaking, but nothing that'll break existing code either, which is exactly the vibe you want from an LTS.

F# 10 adds better C# interop (long overdue) and some computation expression ergonomics. EF Core 11 picks up primitive collection improvements and better JSON column support in Postgres and SQL Server. ASP.NET Core's minimal APIs continue their slow march toward being the default choice over MVC controllers for new services. None of these are revolutionary on their own — the point is they all ship together on a three-year support clock, which is the actual product for enterprise teams.

The community reaction on Hacker News leans positive but cautious. The top-voted comments split roughly along two lines: people who ship .NET in production are happy about the AOT improvements and the LTS timing, and people who don't are mostly asking whether this closes the gap with Go for cloud-native workloads. The honest answer is 'closer, but Go still wins on build simplicity and single-binary deployment.' .NET's Native AOT works, but it still requires more attention to trimming warnings and reflection-heavy libraries than `go build` ever will.

What this means for your stack

If you're on .NET 8 LTS, this is your upgrade target. You have until November 2026 before .NET 8 falls out of support — plan the migration now, because the jump from 8 → 11 is smaller than 6 → 8 was, and the LTS-to-LTS path is what Microsoft actually tests. Skip .NET 10 unless you're already on it; the STS release was a bridge, not a destination.

If you're starting a new service and the deployment target is serverless or containerized, turn on `PublishAot=true` from day one. The constraints it imposes — no runtime reflection, no dynamic code generation — are easier to live with if you build the service that way from the start than if you retrofit it later. Watch for trimming warnings in your dependencies; most popular libraries (Serilog, Polly, MediatR, the major OTel exporters) now have AOT-compatible versions, but older NuGet packages can still blow up at publish time.

If you're on .NET Framework 4.x, nothing about this release changes the calculus — you should have migrated years ago, and the longer you wait, the more expensive it gets. Microsoft has been telling you this since 2019. They still mean it.

Looking ahead

The three-year LTS clock is the real headline. .NET 11 is the version you'll be running in production in 2028, which means the AOT bets Microsoft made this cycle are the ones you'll be living with. The trajectory is clear: AOT becomes the default, the JIT sticks around for workloads that genuinely need it (plugins, dynamic code, some enterprise ERP scenarios), and the runtime gets smaller and faster every release. If you've been waiting for .NET to feel like a serious cloud-native option rather than a Windows-first enterprise stack with a Linux port, this is the release where that framing finally feels dated.