With the release of Preview 4, .NET 11 officially enters the phase where "things get serious". We've moved past the purely experimental period into the territory of concrete features. The infrastructure underlying your web services and Blazor front-ends has become leaner, faster, and noticeably easier to debug.

If you're planning your software modernization roadmap, this preview is a clear signal that it's time to put .NET 11 on the radar.

The Main Highlights of Preview 4

Preview 4 focuses less on front-page announcements and more on sanding down rough edges, while introducing a couple of decisive shifts to async at the runtime level.

1. Runtime Async Enters the Shared Framework

The most important signal from this build is that the shared framework libraries (the BCL and the ASP.NET Core stack) are now natively compiled with runtime async enabled. In Previews 1–3 it was an opt-in feature for your own code; now it's the framework default.

1. Why it matters: Every async "hop" through Kestrel, the pipeline, the HTTP client and EF Core now leverages the runtime's native async machinery, instead of the compiler-generated state machine.
2. The benefit for legacy systems: Modernized applications (e.g. from PowerBuilder or VB6) tend to be extremely "chatty" on async I/O operations. Cleaner stack traces and lower memory allocation pressure will be felt throughout the entire pipeline.

2. HTTP QUERY Method Support in OpenAPI 3.2

The HTTP QUERY method (a verb similar to GET but with a request body) is now recognized in ASP.NET Core's OpenAPI generation.

1. If you set OpenApiVersion = 3.2, the generated document will emit an inline query Path Item field.
2. For backward compatibility with OpenAPI 3.0 and 3.1, the generator will use the x-oai-additionalOperations extension.

Use case: Complex search or reporting endpoints (often derived from old Clarion or Access apps) that easily exceed URL length limits for query parameters. With QUERY you can send the filter structure in the body without losing semantic clarity.

3. TLS Handshake Observability

If you've ever lost an entire afternoon figuring out why an integration partner or an old industrial device refused to communicate with your modernized API, you'll appreciate these diagnostic additions:

1. UseTlsClientHelloListener: A new extension method to inspect the raw ClientHello before TLS negotiation completes.
2. ITlsHandshakeFeature.Exception: A property exposed via connection middleware to log the exact reason a handshake failed.

4. Endpoint Filters and Binding Failures

Until now, endpoint filters in Minimal APIs ran after parameter binding. If binding generated a 400 (Bad Request) error, the filter never saw it.

1. The fix: By setting RouteHandlerOptions.ThrowOnBadRequest = false, your filter can intercept the binding failure and decide how to respond (e.g. log the event, transform the response, or customize the error). This fix will also be backported to .NET 10.0.8.

5. Blazor Virtualize Gets Serious

The Virtualize component gets two important updates for handling real data flows:

1. Variable heights: Correctly handled even above the viewport. Prepend operations (adding at the top) will no longer cause the scroll anchor to jump or shift.
2. AnchorMode parameter: A new [Flags] enum with Beginning (for news/notification feeds where the top must stay fixed) and End options (for chats or logs that must stay anchored to the latest inserted item).

The Big Picture: The 4 Major Themes of .NET 11

Looking at .NET 11's development as a whole, four strategic directions clearly emerge:

1. Async Built Into the Runtime:Drastically reduced "noise" in stack traces (profilers see the real method frames instead of state-machine plumbing), less pressure on the Garbage Collector, and a decisive push for Native AOT.
2. WebAssembly on CoreCLR:Blazor WASM is progressively moving from Mono to a dedicated WebAssembly RyuJIT. In the future, server and browser will share the exact same optimized execution engine.
3. Compression, AI and New Syntax:Native Zstandard support (2 to 7 times faster compression compared to gzip); introduction of the BFloat16 type for AI workloads; vector search in EF Core 11; introduction of Union Types in C# 15.
4. Enhanced SDK and Tooling:dotnet run becomes interactive; support for inline environment variables (dotnet run -e KEY=value); dotnet watch integrates natively with Aspire nodes; container images shrunk by up to 17%.

What Does This Mean for Development Teams?

If you're defining your company's tech roadmap, keep these three points in mind:

1. Target .NET 11 directly for new modernization projects: Even though .NET 10 is an LTS release, the runtime async improvements, WASM convergence, and Blazor optimizations in .NET 11 are exactly what a freshly rewritten application benefits from.
2. Plan a regression pass for async: Since Preview 4 enables runtime async within the shared framework, any unexpected behavior in third-party libraries or deep async code are the first details to monitor in acceptance testing.
3. Re-evaluate Blazor WASM in 2027: If in the past you chose Blazor Server purely for performance or WASM startup time reasons, the arrival of CoreCLR on WebAssembly will radically change the rules of the game.

Useful Resources and Next Steps

1. Download Preview 4 SDK: dotnet.microsoft.com/download/dotnet/11.0
2. Official release notes: dotnet/core repository on GitHub.
3. GA Launch (General Availability): November 2026 at .NET Conf.

The release cadence now calls for one preview a month throughout the summer, followed by Release Candidates in September and October. This gives teams an ideal window to test their applications on Preview 5 or 6 bits and be ready for the fall rollout.