.NET 11 Preview 4: An Engineering Review

Process API: the most significant update in years

System.Diagnostics.Process receives its first substantive update in several release cycles, and it addresses precisely the pain points that library authors have been working around for years. This is directly relevant to our work. IronPDF wraps a Chromium rendering process internally, which means our team has built and maintained custom solutions across the same surface area that Microsoft has now standardized: process spawning, deadlock-free output capture, cross-platform lifetime management, and reliable termination behavior.

The new API surface reads like a catalog of issues that library teams have worked around for years:

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

// One-line execution with no deadlock risk
string output = await Process.RunAndCaptureTextAsync("git", ["log", "-5"]);

// Cross-platform parent-exit behavior
var psi = new ProcessStartInfo("renderer.exe")
{
    KillOnParentExit = true,
};

Imports System.Diagnostics
Imports System.Threading.Tasks

' One-line execution with no deadlock risk
Dim output As String = Await Process.RunAndCaptureTextAsync("git", {"log", "-5"})

' Cross-platform parent-exit behavior
Dim psi As New ProcessStartInfo("renderer.exe") With {
    .KillOnParentExit = True
}

RunAndCaptureTextAsync multiplexes stdout and stderr to eliminate pipe-buffer deadlocks. KillOnParentExit and StartDetached provide cross-platform control over child-process lifetime on Windows and Linux. InheritedHandles enables explicit specification of which handles a child process inherits, replacing the historical default of broad inheritance. The lightweight SafeProcessHandle surface produces NativeAOT binaries up to 20% smaller than the standard API.

For any team building .NET software that orchestrates child processes, this section of the release notes warrants careful review.

For teams that prefer not to build and maintain this infrastructure in-house, IronPDF provides production-tested implementations of these patterns out of the box: deadlock-free output capture, lifetime control, and reliable failure handling. Start a free trial of the Iron Suite, no credit card required.

Span-based Deflate, ZLib, and GZip APIs

This change is less prominent in the release notes but materially improves any workload that processes compressed data. PDF documents contain compressed content streams. XLSX files are ZIP archives of compressed XML. DOCX follows the same pattern. The new span-based encoder and decoder APIs reduce allocations across precisely the operations that libraries such as IronPDF and IronXL perform continuously.

These are infrastructure-level improvements that rarely make release headlines but reduce the cost of every byte processed through the framework.

Runtime Async, now compiled into the framework libraries

Preview 3 removed the preview-feature gate on Runtime Async. Preview 4 extends this further: the runtime libraries themselves (the entire BCL, including System.IO and System.Net.Http) are now compiled with runtime-async. Every async call into the framework now uses the new continuation machinery, regardless of whether the consuming code has enabled the feature.

For libraries that perform substantial I/O (reading files, downloading remote assets, streaming bytes through codecs), this represents a meaningful improvement to dependency performance without requiring any consumer-side changes. Andy Gocke from the runtime team has confirmed that hand-enabled DecompressAsync produces zero additional allocations when backed by a MemoryStream. Microsoft has not yet published official benchmark numbers, citing the need to complete its full performance test suite, but the structural change is in place.

MAUI moves to CoreCLR

This is the most significant architectural change in the release, although direct impact on our product line is limited. Beginning with Preview 4, MAUI applications on Android, iOS, and Mac Catalyst run on CoreCLR by default, concluding more than fifteen years of Mono as the mobile runtime for .NET. The same runtime now powers ASP.NET Core, desktop applications, and mobile. dotnet watch is also now available for Android and iOS, addressing one of the most frequently cited gaps in the MAUI developer experience since its initial release.

For teams using IronBarcode or IronPDF within a MAUI application, the underlying runtime is now unified with the rest of the .NET stack.

Known limitations and considerations

• Visual Studio support remains limited to the Insiders channel. Teams on stable Visual Studio releases are not yet integrating .NET 11 into mainline development.
• Runtime Async has landed structurally but lacks official benchmarks. The widely circulated figure of "10M awaits: 80ms to 32ms, 687MB to 94KB" originates from a community gist rather than Microsoft.
• The MAUI CoreCLR transition is a runtime change shipping as a default. Existing MAUI applications should be tested on physical devices rather than assumed to be a transparent upgrade.
• As with any preview, production deployment should wait for at least the first release candidate.

Summary

Preview 4 represents the strongest set of changes in the .NET 11 cycle to date. The Process API rewrite is the most consequential update for teams building or operating .NET software that spawns child processes. The compression and Runtime Async improvements compound across I/O-intensive workloads. The MAUI runtime story is now consistent with the rest of the platform.

Our team is actively tracking each preview and preparing our libraries for day-one compatibility when .NET 11 reaches general availability in November.