.NET 11.0: What's New, Release History & Support Lifecycle

What Is New in .NET 11

What Is Runtime Async and Why Does It Matter for Async-Heavy .NET Apps?

Runtime Async is the single biggest architectural shift in .NET 11: the runtime itself now understands async methods as a first-class concept, taking over work that the C# compiler has been doing alone since C# 5. Before this change, every async method was lowered by the compiler into a state machine struct that manually tracked suspension points. That worked, but it left the runtime blind to the logical flow of async execution - which is exactly why await-heavy stack traces have always looked like garbage in the debugger.

With Runtime Async, the CLR owns the suspend/resume cycle. Breakpoints now bind correctly inside async methods, and the debugger can step through await boundaries without falling into compiler-generated infrastructure you never wrote. In practice, this alone will save a meaningful amount of time for anyone debugging production issues in async microservices.

Starting with Preview 3, you no longer need <EnablePreviewFeatures>true</EnablePreviewFeatures> to use Runtime Async when targeting net11.0. NativeAOT and ReadyToRun are also supported. To opt in on an earlier preview or for a non-net11.0 target, add both flags:

<PropertyGroup>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
  <Features>$(Features);runtime-async=on</Features>
</PropertyGroup>

Think of Runtime Async as the runtime finally learning to read the same code you wrote, rather than squinting at a compiler translation. The performance gains are real too - fewer allocations per async call and lower overhead on the hot path. This is the change that will compound across every web app, background service, and gRPC endpoint you deploy on .NET 11.

What JIT Improvements Ship with .NET 11 and Will You Actually Feel Them?

The JIT in .NET 11 is meaningfully smarter about removing work it can prove is unnecessary, and the gains show up without any code changes on your part. Here are the four areas worth knowing:

Most teams running on x64 cloud hardware will see the bounds check and switch folding improvements automatically in their next benchmark run. The Arm SVE2 intrinsics are relevant if you are running on newer AWS Graviton or Azure Ampere instances. None of these require a code change - just retarget to net11.0 and recompile.

What Did the SDK Team Actually Ship in .NET 11 for Day-to-Day Developer Workflow?

The SDK changes in .NET 11 are the kind you notice in the first hour after installing. Three of them are genuinely useful in regular development loops.

Smaller installers on Linux and macOS

The SDK installer now deduplicates assemblies using symbolic links, replacing 816 duplicate files (140 MB on Linux x64) with symlinks pointing to a single copy. The archive drops significantly as a result. If you run automated CI installs on Linux, this is an immediate win. Windows deduplication is planned for a future preview.

Pass environment variables to dotnet run

You can now pass environment variables inline with dotnet run instead of exporting them to the shell first:

dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug

These are available to MSBuild as RuntimeEnvironmentVariable items. For anyone who has been sourcing a .env file just to flip an environment before running locally, this removes that ceremony.

Solution filter management from the CLI

dotnet sln can now create and edit .slnf solution filter files directly, using the same subcommands you already know:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

In large monorepos this is a real quality-of-life improvement. You no longer need to hand-edit JSON or open Visual Studio just to adjust which projects load. The dotnet watch tooling also gains Aspire app-host integration and automatic crash recovery in Preview 3, which makes local Aspire development loops noticeably less brittle.

What Breaking Changes in .NET 11 Actually Require Migration Work?

Most .NET 11 breaking changes are narrow, but two of them can catch you off guard depending on your deployment target and library choices.

Minimum hardware requirements raised

The most broadly impactful change is the updated minimum hardware floor. On x86/x64, .NET 11 now requires the x86-64-v2 instruction set (SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT). On Windows Arm64, LSE is now required. In practice, any CPU still officially supported by Intel, AMD, or the Windows operating system already satisfies this. Chips that fall outside that range went out of support around 2013. If you run .NET on genuinely old hardware or unusual embedded targets, verify before upgrading.

Mono launch target removed for .NET Framework on Linux

The SDK no longer auto-configures RunCommand and RunArguments to use Mono when you run dotnet run on a .NET Framework project targeting Linux. This is a behavioral change with a clear workaround - set those properties explicitly in your project file - but it will silently break any pipeline that relied on the old automatic behavior. Mono ownership has moved on, and the .NET SDK is making that separation official.

ASP.NET Core and library changes to watch

• Virtualize<TItem>.OverscanCount defaults from 3 to 15. Blazor apps that relied on the old default for layout calculations may see scrolling behavior change.
• Microsoft.AspNetCore.OpenApi now targets OpenAPI 3.2.0 via Microsoft.OpenApi 3.3.1, which has upstream breaking changes. Review the Microsoft.OpenApi upgrade guide before updating API doc generation code.
• ASP.NET Core Identity moves all time-based logic to TimeProvider. Custom token providers or test harnesses that hook into DateTime.UtcNow directly will need updating.

What Did .NET 11 Add to System.Text.Json and the Base Class Libraries?

The library additions in .NET 11 are focused rather than sprawling - a few genuinely useful APIs rather than a kitchen-sink expansion.

System.Text.Json gets three worthwhile improvements. First, JsonNamingPolicy.PascalCase is now built in, which is useful when you are generating JSON for systems that expect PascalCase rather than the camelCase default. Second, you can now apply a naming policy at the individual member level rather than only at the type level, which handles the case where one field in a contract has to match an external convention the rest of the type does not use. Third, type-level ignore conditions let you annotate a type to control which members are included or excluded globally.

Compression gains two practical additions. Zstandard (zstd) lands in System.IO.Compression as a first-class codec alongside GZip and Brotli - no more pulling in a third-party NuGet package for zstd support. ZIP entry reading now validates CRC32 on extraction, which catches corrupted archives that previously would silently produce bad data.

Low-level I/O fills a couple of gaps: SafeFileHandle can now report whether a handle refers to a pipe and can create anonymous pipes, and RandomAccess gains read/write support for non-seekable handles. These are plumbing APIs, but the teams building cross-platform process interop or custom I/O layers will know exactly where they fit.

Strings and numerics round things out with Rune-based operations on String (useful for correct Unicode text processing), BFloat16 in BitConverter (relevant for ML inference pipelines that work with 16-bit brain float), and a Matrix4x4 performance improvement that benefits any graphics or physics code running on the BCL types.

Reference

Source: What's new in .NET 11 - Microsoft Learn