What’s New in .NET 11 Preview 2

Microsoft shipped .NET 11 Preview 2 on March 10, 2026, exactly one month after Preview 1. While Preview 1 gave us the architectural bones like Zstandard compression and CoreCLR on WebAssembly, Preview 2 is where the rubber actually meets the road. 

This release is less heavy on syntax updates but brings some sweet updates to Runtime Async, serious performance bumps for Kestrel, native OpenTelemetry in ASP.NET Core, and AI-friendly vector search in EF Core.

Here is a summary of what’s new, what’s changed, and what it means for your modernization roadmap. 

Runtime Async V2: Say Goodbye to Garbage Stack Traces

Preview 1 teased Runtime Async as a concept, making async a first-class citizen in the runtime with CoreCLR support enabled by default. But since none of the core runtime libraries were compiled for it yet, its practical impact was limited to experimenting.

Preview 2 delivers Runtime Async V2, and the difference is very satisfying. If you've ever had the pleasure of debugging a converted legacy app where synchronous VB6 or PowerBuilder event handlers were brute-forced into C# async methods, you know the pain. The second you hit an await, the stack trace becomes an unreadable nightmare. 

• The Old Way: A simple chain of three async methods produces 13 stack frames, heavily cluttered with state-machine junk like AsyncMethodBuilderCore.Start and synthetic MoveNext methods.
• The New Way: With Runtime Async enabled, that exact same call chain produces just 5 frames, showing only your actual code.

This doesn't just make your life easier in the IDE; it makes 2 AM production exceptions actually readable in your logging platform. It also tackles a classic modernization pitfall: deadlocks caused by mixing new async code with legacy synchronous components. 

Just remember it's still in preview, so you have to manually opt-in using <Features>runtime-async=on</Features> and <EnablePreviewFeatures>true</EnablePreviewFeatures> in your project file. 

Kestrel & Observability: Hardening for the Real World

Under the hood, Kestrel’s HTTP/1.1 request parser got a massive 20-40% throughput boost when dealing with hostile traffic. Previously, the parser would throw a BadHttpRequestException every time it hit a malformed request, which added up to severe overhead during heavy port scanning or misconfigured client spam. Preview 2 replaces this with a non-throwing code path that returns a result struct (success, incomplete, or error) instead. You get zero impact on valid request processing, but vastly better survival rates against bad traffic.

This is a massive win for legacy apps that used to hide behind strict firewalls and are now being exposed to the harsh reality of internet probing via ASP.NET Core. Plus, the HTTP logging middleware now pools its response buffering streams, cutting down per-request allocations when logging is enabled (which you're probably doing heavily during migration validation). 

On the observability side, ASP.NET Core now bakes OpenTelemetry semantic convention attributes directly into the HTTP server activity. 

• Attributes like http.request.method, url.path, http.response.status_code, and server.address populate automatically.
• You no longer need to bolt on the OpenTelemetry.Instrumentation.AspNetCore package.
• Just subscribe to the Microsoft.AspNetCore activity source and the data flows naturally.

Observability is usually the most underestimated requirement when dragging a client-server system into a distributed web architecture, so having this built-in drastically reduces setup friction from day one. 

Blazor and the Web: Pragmatic Fixes

For the frontend, Blazor Server-Side Rendering (SSR) finally supports TempData. If you're migrating WebForms or classic ASP.NET MVC apps, the POST-Redirect-GET pattern is everywhere. Previously, doing this in Blazor SSR forced developers to hack together external state stores. Now, it's automatically registered via AddRazorComponents() as a cascading value, using ASP.NET Core Data Protection for cookie encryption. It’s a tiny feature that closes a huge gap for migration fidelity.

Microsoft also introduced a first-class .NET Web Worker project template. If your legacy desktop app relied on background threads for heavy data processing or report generation, you can now push that logic into a Web Worker, keeping it safely off the Blazor UI thread in the browser. 

EF Core: Vector Search and LINQ Upgrades

EF Core 11 Preview 2 brings a cluster of data access improvements tailored for both modernization and AI-augmented applications:

• LINQ MaxBy and MinBy: You can now express these common query patterns directly in LINQ without dropping down to raw SQL, providing a cleaner translation path for legacy apps that relied on stored procedures for sorting.
• Vector Search: SQL Server DiskANN vector indexes and VECTOR_SEARCH() are now natively supported. If your roadmap includes adding AI (like RAG or semantic search) to a legacy system, you can build it using your existing EF Core data access layer.
• Full-Text Search: You can create and manage SQL Server full-text catalogs and indexes directly without leaving the EF Core model.
• JSON Queries: JSON_CONTAINS() support is here for checking semi-structured data inside SQL Server columns, which is a lifesaver when migrating away from overly flexible legacy data models.

SDKs, MAUI, F#, and Odds & Ends

There’s a lot of housekeeping in Preview 2 that will make your pipelines and daily coding less annoying:

• Library tweaks: System.Text.Json got generic overloads for GetTypeInfo() and TryGetTypeInfo() to stop you from casting metadata. TarFile.CreateFromDirectory finally lets you specify cross-platform archive formats (Pax, Ustar, GNU, and V7) instead of just Pax. And Matrix4x4.GetDeterminant is about 15% faster for simulation workloads.
• Smaller footprint: Linux and macOS SDK installers shrank by up to 26% thanks to symlink assembly deduplication, and SDK container images are up to 17% smaller, meaning faster CI/CD pipelines.
• Code analyzers: CA1873 was tweaked to produce less noise, and bugs in CA1515, CA1034, and CA1859 were squashed.
• OpenAPI Breaking Change: ASP.NET Core's OpenAPI support was bumped to version 3.2.0. This aligns .NET with the latest specs, but it is a breaking change, so check your API gateways and client generators before upgrading.
• MAUI & CoreCLR: .NET MAUI gets asynchronous map tile loading to reduce UI stutter, performance refactoring for TypedBinding to kill unnecessary allocations, and immutability annotations for Color and Font types. Microsoft is also heavily pushing CoreCLR over Mono: Android now requires API 24+ (Android 7.0), and experimental CoreCLR support just landed for iOS, Mac Catalyst, macOS, and tvOS.
• Language Features: C# 15 and Visual Basic are quiet this round (beyond the Collection Expression Arguments from Preview 1). F#, however, gets simplified DIM interface hierarchies, overload resolution caching for faster compilation, an #elif preprocessor directive, and a partition function for collections.

What's Missing?

The core runtime libraries still aren't compiled with runtime-async, which is the missing puzzle piece for seeing its full performance impact in the wild (expected in upcoming previews). And if you're waiting for massive Windows Forms or WPF overhauls, you'll be waiting a while. .NET 11 is mostly just doing quality fixes for those legacy desktop workloads.

The Bottom Line for Modernization

Two previews in, .NET 11 is clearly an infrastructure release and that's exactly what we want. The improvements here including Runtime Async, native observability, Kestrel hardening compound over time and reduce daily friction in production.

For our VELO modernization platform, Runtime Async V2 is incredibly relevant. When VELO automatically converts legacy synchronous code to modern async C#, getting cleaner stack traces and reduced allocation overhead makes the output of our automated tools measurably better from day one. 

 Our guidance remains steady: 

• Target .NET 10 for production migrations today. It's LTS and it's stable.
• Experiment with .NET 11 previews in dev/test to validate how Runtime Async and EF Core vector search behave with your workloads.
• If you're still using .NET 8 or 9, start moving. Both lose support in November 2026.
• Keep an eye out for Preview 3+ to see the core libraries finally get runtime-async compilation.

We'll be tracking every .NET 11 preview as it ships. If your team is staring down the barrel of a legacy modernization and wants to sequence it correctly against these platform changes, let's talk. GAPVelocity AI's VELO platform delivers 85-95% automated code coverage for legacy-to-modern .NET migrations, with AI Squads handling the last mile.