.NET 11 Preview 6: Three Changes That Will Break Your CI

.NET 11 Preview 6 dropped July 14, and buried in the changelog is a change already breaking CI pipelines in silence: AddOpenApi() now generates OpenAPI 3.2 documents by default. If your pipeline runs a schema diff, generates a client from that spec, or validates an API contract, it will start failing the moment you add <TargetFramework>net11.0</TargetFramework>. That is the kind of quiet trap worth knowing before the November 10 GA ships under the radar. There are two other changes in Preview 6 worth your attention now, not at RC time.

1. OpenAPI 3.2 Is Now Default — and Swashbuckle Is Not Ready

In every previous .NET 11 preview, AddOpenApi() without explicit version configuration produced an OpenAPI 3.1 document. Preview 6 flips that switch. New and upgraded projects now generate OpenAPI 3.2 output by default, and Microsoft’s OpenAPI library bumped to 3.x (currently 3.6.0) — a major version boundary. The types your document and operation transformers receive have changed shape, which means existing transformer code may not compile after the upgrade.

The more immediate problem is tooling. Swashbuckle.AspNetCore has an open issue for OpenAPI 3.2 support that was not resolved as of this writing. If your team uses Swashbuckle for UI generation or client code scaffolding, Preview 6 may break your build before any of your actual application code changes.

The fix is a single line:

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_1;
});

Pin to 3.1 now, test your toolchain against 3.2 in a branch, and upgrade on your own schedule rather than at GA crunch time. Microsoft documents this as a formal breaking change, which is worth flagging to your team lead if they are tracking upgrade risk.

2. Async Validation in ASP.NET Core: The Pattern You Have Been Faking

If you have built validation that checks a database — whether an email is taken, whether a slug is unique, whether a product ID exists — you have probably worked around ASP.NET Core’s synchronous-only DataAnnotations system. Common workarounds include FluentValidation middleware, custom action filters, or moving the check to a service layer and lying in the attribute. Preview 6 ends that.

Two new types ship in this release: AsyncValidationAttribute and IAsyncValidatableObject. The Microsoft.Extensions.Validation layer now calls the async path end-to-end when validating Minimal API endpoints:

public class UniqueEmailAttribute : AsyncValidationAttribute
{
    protected override async Task<ValidationResult?> IsValidAsync(
        object? value, ValidationContext ctx, CancellationToken ct)
    {
        var db = ctx.GetRequiredService<AppDbContext>();
        return await db.Users.AnyAsync(u => u.Email == (string?)value, ct)
            ? new ValidationResult("Email already registered.")
            : ValidationResult.Success;
    }
}

There is one gotcha before you write your first implementation. IAsyncValidatableObject extends IValidatableObject, so the compiler requires you to implement the synchronous Validate method as well — even though the framework never calls it on this path. If your validation is genuinely async-only and you cannot provide a meaningful sync implementation, throw InvalidOperationException from the sync method. That is the documented pattern.

Note that this runs only on Minimal API endpoints that opt into validation via Microsoft.Extensions.Validation. MVC controllers use a separate pipeline and are not affected in Preview 6.

3. Runtime-Async Performance: Two Changes Worth Benchmarking

Neither of these requires a code change, but both matter if you maintain high-throughput async services.

First: the ExecutionContext capture overhead is gone for continuations that do not need it. Previously, every Task continuation captured an ExecutionContext snapshot and restored it before running — even when no AsyncLocal<T> was in use and the restore was a no-op. The runtime now detects that case and skips the cycle. Apps that use ConfigureAwait(false) and avoid AsyncLocal state in hot paths will see the biggest benefit. This applies to Task, Task<T>, ValueTask, and ValueTask<T>.

Second: the JIT now compiles a dedicated runtime-async version of synchronous task-returning methods instead of delegating through a thunk. One fewer layer of indirection per async call. For most CRUD APIs this is noise. For services handling tens of thousands of concurrent requests, the official release post suggests running a benchmark — particularly if you are already tracking thread pool pressure.

Also in Preview 6

Four new stream adapter types land in the base libraries: ReadOnlyMemoryStream, WritableMemoryStream, ReadOnlySequenceStream, and StringStream. These wrap in-memory buffers as Stream instances without copying into a MemoryStream first — useful for middleware authors passing pipeline output to Stream-expecting APIs.

C# union support types now ship as part of the base class library, so library authors no longer need a separate NuGet package for union runtime support, and System.Text.Json serializes union types natively. Extension members in C# now include indexers, rounding out the feature introduced in .NET 10. EF Core Preview 6 adds LINQ translation improvements and support for complex-type property traversal. SignalR clients can now refresh authentication tokens during long-lived connections. The full ASP.NET Core Preview 6 release notes have the complete list.

What to Do Before November 10

GA is 17 weeks out. Preview 7 is expected in August, RC1 in September.

Do now: Test your OpenAPI toolchain against Preview 6 output — run your schema diff, codegen, or contract tests against a Preview 6 branch and find the breakage before your migration deadline arrives. Audit your IValidatableObject implementations to identify which ones need async migration paths. The Visual Studio Magazine Preview 6 roundup is a solid starting point for the full component-level inventory.

Wait for RC1: Production migrations, publishing library packages targeting .NET 11, and any final API decisions on C# union types (still marked preview language). .NET 10 remains the LTS choice for stability-focused teams — it is supported through November 2028 and has a year of production hardening behind it.