.NET 11 Release Date Confirmed: What's New and How to Prepare

Microsoft has confirmed that .NET 11 will reach general availability on November 10, 2026, timed to the opening day of .NET Conf 2026. The release has already cleared Release Candidate 2 on October 13, 2026, which ships with a go-live license — meaning it's supported for production use while teams wait on the final build. Here's what's actually confirmed in .NET 11 so far, what's still being clarified, and how to get a codebase ready before the switch.

When is the .NET 11 release date?

Microsoft's own .NET support-policy page and the official .NET Conf 2026 site both point to the same date: November 10, 2026. That's not a coincidence — Microsoft has used its annual .NET Conf event to launch every major .NET version since .NET Core shipped, and .NET 11 is no exception. The timing also closes a loop: .NET 9, the Standard Term Support release two versions back, reaches its own end of support on that identical day, so November 10, 2026 is simultaneously a launch date and a retirement date on Microsoft's release calendar.

Ahead of general availability, .NET 11 moved from preview into release-candidate status in September 2026. RC2 shipped on October 13, 2026, alongside routine servicing updates for .NET 10, 9 and 8. Like RC1 before it, RC2 carries Microsoft's go-live license, the designation the company uses to tell teams a pre-release build is stable enough to deploy in production ahead of the final release.

RC2 and the final stretch before GA

The RC2 announcement on Microsoft's .NET blog groups its changes into the usual buckets: libraries, runtime, SDK, MSBuild, NuGet, F# and ASP.NET Core, with .NET MAUI and Windows Forms updates alongside. Some of the smaller but practical additions in RC2 include incremental CBOR reading via a streaming CborReader, experimental composite ML-KEM and HPKE post-quantum cryptography APIs, a way to configure initial HTTP/2 concurrency before a server's first SETTINGS frame arrives, and a CLI option to set a minimum package-publication age when adding a NuGet source — a small anti-supply-chain-attack guardrail. On the ASP.NET Core side, RC2's one headline change is that QuickGrid's virtualization APIs are no longer marked experimental, which matters if you've been avoiding them in production because of that label.

What RC2 doesn't do is lock the feature set. Microsoft's own "what's new" documentation for .NET 11 is explicitly still being written against RC2, and a handful of C# 15 features are described in the docs as previews that could still change before the final cut.

Native AOT in .NET 11: what's actually default now

This is the detail most likely to get garbled in the retelling, so it's worth being precise about it. Starting with .NET 11, the dotnet CLI itself now runs through a Native AOT-compiled native entry point by default, alongside the MSBuild build server. In practice that means common CLI invocations — the ones that don't need MSBuild or NuGet in-process, such as simple command dispatch and --help — start faster because they skip the managed CLI's own startup cost. Commands that do need MSBuild or NuGet in-process, like build, run, test, pack and publish, still fall back to the managed CLI path. You can opt back into the old behavior with the DOTNET_CLI_ENABLEAOT environment variable.

That is a real, confirmed default-on change — but it's a change to the tool you type commands into, not a change to how your own ASP.NET Core or console projects publish. Native AOT publishing for your own apps (dotnet publish -p:PublishAot=true, or the dedicated AOT web API template) still needs to be opted into project by project in .NET 11, the same as in .NET 8 through .NET 10. Where NativeAOT genuinely gets faster in .NET 11 is under the hood: interface dispatch on AOT-published apps now routes through a shared, patchable dispatch helper that Microsoft says both shrinks binary size at call sites and improves throughput on interface-heavy code, and generic virtual dispatch gets the same treatment.

C# 15: unions, closed hierarchies and a multi-release push on memory safety

C# 15 is the default language version once a project targets .NET 11, and Microsoft's C# documentation lists six features tied to it, all still flagged as preview at RC2:

• Union types — a new union keyword declares a type whose value is one of several case types, with implicit conversions from each case and compiler-checked exhaustive switch expressions. Minimal APIs can already return unions directly, and ASP.NET Core serializes them to JSON and represents them as anyOf in generated OpenAPI documents.
• Closed hierarchies — a closed modifier restricts which assembly can derive from a type, which lets the compiler treat a switch over every known subtype as exhaustive without a default arm.
• Collection expression arguments — constructor arguments such as a capacity or comparer can now be passed inside collection-expression syntax.
• Extension indexers — indexers can be declared inside an extension block.
• Labeled break and continue — these statements can now target a label on an enclosing construct instead of only the nearest loop.
• Memory safety — the first stage of a stated multi-release effort to tie the unsafe context to operations that actually touch unmanaged memory, rather than to the mere presence of pointer types.

Underneath the language, .NET 11's runtime adds its own asynchronous-programming shift: Runtime Async (what Microsoft is calling Runtime Async V2) replaces compiler-generated async state-machine classes with runtime-managed suspension and resumption for methods that opt in. The practical payoff shows up in debugging — live stack traces during execution shrink dramatically, since the actual async call chain appears directly instead of being buried in state-machine infrastructure frames — plus lower allocation overhead on hot await paths. It no longer requires the old EnablePreviewFeatures switch on a net11.0 target, though it's still an opt-in preview feature enabled per project via <Features>runtime-async=on</Features>.

ASP.NET Core and Blazor: what actually changed

Per Microsoft's ASP.NET Core 11 release notes, Blazor picks up a long list of incremental fixes rather than one headline feature. A new <BasePath /> component renders the app's base-path tag automatically; NavigateTo and NavLink gain a RelativeToCurrentUri option for navigating relative to the current page instead of the app root; and antiforgery protection in Blazor Web Apps is now automatic, so app.UseAntiforgery() is no longer something you have to remember to wire up yourself. The Virtualize component's default OverscanCount jumps from 3 to 15, and it gains support for variable item heights and programmatic scroll-to-item. Blazor WebAssembly's old dev server is being replaced by a new, lighter Microsoft.AspNetCore.Components.Gateway host.

Two changes are worth flagging for teams running Blazor Server at scale: a server-triggered circuit-pause capability lets the server ask connected clients to pause gracefully (useful during deployments), and there's now an opt-in automatic-pause package for inactive browser tabs. Minimal APIs, separately, get endpoint filters that now run even when parameter binding fails, letting you observe or replace a 400 response instead of never seeing the request at all. An experimental Microsoft.AspNetCore.Components.AI package also appears in prerelease, adding chat-UI building blocks (ChatPage, UIAgent) that work with any IChatClient — an early signal of where Microsoft expects Blazor apps to head next, not a stable feature to build on yet.

Runtime performance: the changes you won't have to opt into

Several of .NET 11's performance wins apply automatically, without any code change. Microsoft's runtime documentation highlights Comparer<T>.Default and EqualityComparer<T>.Default now being specialized ahead-of-time in ReadyToRun images instead of falling back to reflection-driven JIT compilation, which the team measured at up to a 20x improvement for collection operations that rely on the default comparer. On platforms without JIT support, such as iOS, cached interface dispatch is reported to yield up to 200x improvements in interface-heavy code versus the previous generic fallback path. Guid.NewGuid() on Linux switches to the getrandom() syscall with batch caching, for roughly a 12% throughput gain.

The one performance-adjacent change that isn't free: .NET 11 raises its minimum hardware baseline. The x86/x64 floor moves from x86-64-v1 to x86-64-v2 on Windows, Linux and macOS alike (guaranteeing instruction sets like SSE4.2 and POPCNT that virtually all CPUs sold since around 2013 support), and Arm64 on Windows now requires the LSE instruction set, matching what Windows 11 already mandates. Apple and Raspberry Pi-class Arm64 hardware are unaffected. If you're still deploying to genuinely old x86-64 or Arm64 hardware, .NET 11 is expected to refuse to run and print a message that the CPU is missing a baseline instruction set — worth checking against your fleet before you upgrade, not after.

.NET 11 vs .NET 10: should you move?

The honest answer depends on which release you're coming from, because .NET 10 and .NET 11 sit on opposite ends of Microsoft's support model.

If you're on .NET 10 today, there's no urgency: it's the current LTS release, it's only a year into a three-year support window, and nothing in .NET 11 looks like a must-have for a production LTS app. .NET 11 is squarely aimed at teams that want this cycle's C# 15 features, the Runtime Async improvements, or the latest ASP.NET Core/Blazor additions now rather than waiting for .NET 12 (the next LTS, expected November 2027). If you're still on .NET 8 or .NET 9, the more pressing fact is that .NET 9 goes out of support on the same day .NET 11 ships — November 10, 2026 — so that migration decision needs to happen regardless of whether .NET 11 or .NET 10's LTS is the destination.

Support lifecycle: why STS matters here

.NET 11 is a Standard Term Support release, not Long Term Support — Microsoft's cadence alternates LTS and STS releases each year, and .NET 10 already claimed the LTS slot for this cycle. Under Microsoft's current policy, which it revised in September 2025, STS releases get roughly two years of free support and patches, specifically ending 12 months after the next release ships, rather than the shorter 18-month/6-month window the policy used before that change. Applied to .NET 11, that means its own end-of-support date isn't fixed yet — it depends on exactly when .NET 12 ships next November — but teams should plan on roughly a two-year patch window, not three. If your app needs to stay on one major version for years at a time without a forced upgrade, .NET 10's LTS status makes it the safer target even after .NET 11 is out.

How to prepare for .NET 11

1. Check your minimum hardware baseline first. If any build or deployment target is an older x86-64-v1-only CPU, or a non-Apple Arm64 device missing the LSE instruction set, test it against RC2 before GA — Microsoft says .NET 11 will refuse to launch rather than silently degrade.
2. Install the RC2 go-live build in a non-production slot from Microsoft's official .NET 11 download page to catch compatibility issues against your existing test suite now, rather than on launch day.
3. Audit anything depending on DOTNET_RuntimeAsync or UNSUPPORTED_RuntimeAsync environment variables if you experimented with earlier Runtime Async previews — those variables were removed; use the UseRuntimeAsync MSBuild property instead.
4. Decide LTS vs. STS deliberately. New projects that need to minimize how often they're forced to re-platform should default to .NET 10's LTS track; projects that want this generation's C# 15 and ASP.NET Core features now, and can tolerate re-platforming again in roughly two years, are the better fit for .NET 11.
5. Watch the .NET Conf 2026 sessions for the finalized feature list — several C# 15 and Blazor items are still documented as preview and subject to change between RC2 and GA.

.NET Conf 2026: the official launch event

Microsoft is using .NET Conf 2026, the 16th annual edition of the free virtual event, as the formal launch moment for .NET 11. The event's own announcement post describes three core days of sessions, community content and the .NET 11 launch starting November 10, with the main .NET Conf site now also listing a community day extending into November 13. Sessions are expected to cover keynote announcements, technical deep dives into the runtime and language changes above, and hands-on guidance for migrating existing apps — the kind of detail that typically fills in gaps left in pre-release documentation. Registration is free and the full agenda is published on the event's own site closer to the date.

What to watch next

Between now and November 10, expect two more points of confirmation: a possible RC3 servicing build in the final weeks before GA (Microsoft's own release-candidate cadence has run roughly every two to three weeks this cycle), and the finalized C# 15 spec once features currently marked preview — union types and closed hierarchies especially — lock before the stable release. Teams managing a broader platform upgrade cycle alongside .NET 11 may also find it worth lining up with other runtime updates landing around the same window, including Node.js 26's own LTS release for teams running mixed .NET and Node services, and revisiting how your CI/CD pipeline handles major runtime bumps before rolling either one out. And if your .NET services were among those affected by the actively exploited Brotli decompression flaw patched earlier this year, this upgrade cycle is a reasonable checkpoint to confirm every affected service picked up that fix.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage