New Features in .NET 11 and C# 15

.NET 11 and C# 15 is out today (November 10, 2026).

.NET 11 is a Standard-Term Support (STS) release. STS releases now get 24 months of support, so .NET 11 will be supported until November 2028.

This release brings the language feature C# developers have been asking for over a decade: Union Types (Discriminated Unions).

The runtime starts replacing compiler-generated async state machines with native async support, a major step toward improved performance.

This is one of the best releases in .NET in years.

In this post, we will explore:

• What's New in .NET 11
• What's New in C# 15
• What's New in .NET 11 Libraries
• What's New in ASP .NET Core in .NET 11
• What's New in EF Core 11
• Breaking Changes in .NET 11

Let's dive in!

Runtime Async

The biggest runtime change in .NET 11 is runtime-native async (Runtime Async).

Since C# 5, the compiler has turned every async method into a hidden state machine class. This class tracks where your method paused and how to resume it. It worked for over a decade, but it adds allocations, extra code, and noisy stack traces.

With Runtime Async, the runtime itself handles suspension and resumption. The compiler no longer needs to generate state machines.

To enable Runtime Async in your project, add the following property:

xml
1<PropertyGroup>
2  <Features>runtime-async=on</Features>
3</PropertyGroup>

The .NET runtime libraries themselves are already compiled with Runtime Async, so part of the benefit comes for free in every .NET 11 app.

Cleaner Live Stack Traces

The most visible change is in live stack traces: what profilers, debuggers, and new StackTrace() see while your code runs.

Consider three nested async methods:

csharp
1await OuterAsync();
2
3static async Task OuterAsync()
4{
5    await Task.CompletedTask;
6    await MiddleAsync();
7}
8
9static async Task MiddleAsync()
10{
11    await Task.CompletedTask;
12    await InnerAsync();
13}
14
15static async Task InnerAsync()
16{
17    await Task.CompletedTask;
18    Console.WriteLine(new StackTrace(fNeedFileInfo: true));
19}

Without Runtime Async, you get 13 frames with state-machine infrastructure mixed into your call chain:

text
1   at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
2   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
3   at Program.<<Main>$>g__InnerAsync|0_2()
4   at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
5   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
6   at Program.<<Main>$>g__MiddleAsync|0_1()
7   at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
8   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
9   at Program.<<Main>$>g__OuterAsync|0_0()
10   at Program.<Main>$(String[] args) in Program.cs:line 3
11   at System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](...)
12   at Program.<Main>$(String[] args)
13   at Program.<Main>(String[] args)

With Runtime Async, you get 5 frames, which is your real call chain:

text
1   at Program.<<Main>$>g__InnerAsync|0_2() in Program.cs:line 24
2   at Program.<<Main>$>g__MiddleAsync|0_1() in Program.cs:line 14
3   at Program.<<Main>$>g__OuterAsync|0_0() in Program.cs:line 8
4   at Program.<Main>$(String[] args) in Program.cs:line 3
5   at Program.<Main>(String[] args)

Breakpoints also bind correctly inside async methods, and the debugger steps over await without jumping into generated code.

Note: Exception stack traces already look clean today, because ExceptionDispatchInfo removes the noise. The improvement is in what you see during live execution.

Faster Async Code

Runtime Async is also faster. According to the Performance Improvements in .NET 11 post:

• Synchronous completion: A two-level async chain that completes synchronously went from 21.2 ns and 144 B to 6.2 ns and 0 B.
• Real suspension: The same chain after a real await went from 254 ns to 117 ns.
• Exceptions: Throwing through 30 async layers went from 51.3 μs and 84.2 KB to 10.7 μs and 5.7 KB.
• Code size: A ten-layer sample shrank from 10,752 to 5,632 bytes.

The runtime also skips capturing and restoring ExecutionContext when a continuation has nothing to restore. ExecutionContext carries ambient state like AsyncLocal<T> across await points. If you don't use AsyncLocal<T>, every await gets cheaper. This works for Task, Task<T>, ValueTask, and ValueTask<T>, even without the Runtime Async switch.

If you want to stop using this feature, you can opt out per project (or via Directory.Build.props):

xml
1<PropertyGroup>
2  <UseRuntimeAsync>false</UseRuntimeAsync>
3</PropertyGroup>

Your existing code gets faster in .NET 11 without a single change.

The JIT compiler got smarter at removing checks you never asked for. For example, it now removes the bounds check after an empty-span guard:

csharp
1if (!span.IsEmpty && span[0] == value)
2{
3    // The bounds check on span[0] is now eliminated
4}

It also folds string comparisons with constants after inlining:

csharp
1static bool IsAdmin(string role) => role == "Admin";
2
3// When the caller passes "Guest", the JIT replaces the whole comparison with false
4var isAdmin = IsAdmin("Guest");

A few more numbers from the release:

• Enumerators on the stack: Iterating an IEnumerable<int> field went from 13.9 ns and 32 B to 2.7 ns and 0 B.
• Devirtualization: Calling a generic method through an interface went from 6.7 ns and 24 B to 1.8 ns and 0 B.
• Default comparers in ReadyToRun: Collections that use EqualityComparer<T>.Default run up to 20x faster in R2R images.
• GUIDs on Linux: Guid.NewGuid() is about 12% faster.

You can read about hundreds of other improvements in the Performance Improvements in .NET 11 post by Stephen Toub.

.NET 10 introduced file-based apps: you can run a single .cs file with dotnet run main.cs, without a project or a solution.

.NET 11 removes the biggest limitation: you can now split a file-based app across multiple files with the #:include directive:

csharp
1#:include models/order.cs
2#:include services/order-service.cs
3
4var service = new OrderService();
5var order = service.Create("ORD-001", 99.99m);
6
7Console.WriteLine($"Created order {order.Number}");

You can also include compiled DLLs directly:

csharp
1#:include ./libs/Shipping.Contracts.dll
2
3var request = new Shipping.Contracts.CreateShipmentRequest("ORD-001");

The #:property directive now supports quoted values, and the #:package directive accepts item metadata like Aliases:

csharp
1#:property Company="Anton Dev Tips"
2#:package System.CommandLine@2.0.1 Aliases=CommandLine

The CLI gets 3 new options:

bash
1# Pass environment variables to the app
2dotnet run -e ASPNETCORE_ENVIRONMENT=Development -e LOG_LEVEL=Debug main.cs
3
4# Add a project reference to a file-based app
5dotnet reference add --file main.cs ../Orders.Domain/Orders.Domain.csproj
6
7# Format a file-based app
8dotnet format main.cs

File-based apps start faster too, because the CLI reuses the cached Native AOT build output.

I wrote a detailed guide on file-based apps with multi-file support, including an HTTP health-check tool and a Minimal API with EF Core. You can read it here.

You can see the complete list of new features in .NET 11 here.

C# 15 brings the biggest change to the type system in years.

Here are the key features:

A union declares that a value is exactly one of a fixed set of types. The compiler checks that your switch expressions handle every case.

Before C# 15, you had two imperfect options:

• object, which accepts any type at all
• A marker interface or a base class, which anyone can implement or extend
• A third-party library that emulates this behavior

Neither lets the compiler know the full list of possible types.

Example 1: Payment Methods

A checkout service accepts several payment methods, and each one carries different data:

csharp
1public record class CreditCard(string Number, string Holder, DateOnly Expiry);
2public record class PayPal(string Email);
3public record class BankTransfer(string Iban, string Bic);
4
5public union PaymentMethod(CreditCard, PayPal, BankTransfer);

The case types don't need a common base class. The compiler adds implicit conversions from each case type, so you can assign any of them directly:

csharp
1PaymentMethod payment = new PayPal("john@example.com");
2
3string description = payment switch
4{
5    CreditCard card => $"Card ending in {card.Number[^4..]}",
6    PayPal paypal => $"PayPal account {paypal.Email}",
7    BankTransfer transfer => $"Bank transfer to {transfer.Iban}"
8};

Notice there is no _ or default branch. If you add a fourth payment method later, every switch that doesn't handle it produces a compiler warning.

Example 2: Handler Results

Unions are a natural fit for handlers that return one of several outcomes instead of throwing exceptions:

csharp
1public record class OrderCreated(Guid OrderId, string Number);
2public record class OrderAlreadyExists(string Number);
3public record class InvalidOrder(string Reason);
4
5public union CreateOrderResult(OrderCreated, OrderAlreadyExists, InvalidOrder);

The endpoint maps each outcome to an HTTP response:

csharp
1app.MapPost("/orders", async (
2    CreateOrderRequest request,
3    CreateOrderHandler handler,
4    CancellationToken cancellationToken) =>
5{
6    var result = await handler.HandleAsync(request, cancellationToken);
7
8    return result switch
9    {
10        OrderCreated created => Results.Created($"/orders/{created.OrderId}", created),
11        OrderAlreadyExists exists => Results.Conflict($"Order {exists.Number} already exists"),
12        InvalidOrder invalid => Results.BadRequest(invalid.Reason)
13    };
14});

The compiler won't let you forget an outcome.

Example 3: Unions in JSON and APIs

System.Text.Json supports unions out of the box. The serializer writes the active case directly, without a wrapper or $type field:

csharp
1public union OrderReference(int, string);
2
3app.MapGet("/orders/{id:int}/reference", async (int id, OrdersDbContext dbContext) =>
4{
5    var order = await dbContext.Orders.FindAsync(id);
6
7    if (order?.ExternalNumber is not null)
8    {
9        return new OrderReference(order.ExternalNumber);
10    }
11
12    return new OrderReference(id);
13});

This endpoint returns either the numeric ID, like 42, or the external order number, like "EXT-1042". In OpenAPI, the response is described with an anyOf schema that lists each case type.

Unions work in Minimal API and MVC request and response bodies, SignalR, and Blazor. They don't work for route values, query strings, headers, or form fields.

Union types offer much more: custom unions, null handling, and non-boxing access for performance-sensitive code.

Union types work great when the case types are unrelated. But sometimes you have a hierarchy of related types, and you want the same exhaustiveness checks.

That's where closed hierarchies come in.

You can mark a class with the closed modifier. A closed class can only be derived from inside its own assembly.

Here's a shipment status hierarchy:

csharp
1public closed record class ShipmentStatus;
2
3public record class Pending(DateTime CreatedAt) : ShipmentStatus;
4public record class Dispatched(string Carrier) : ShipmentStatus;
5public record class InTransit(string TrackingNumber) : ShipmentStatus;
6public record class Delivered(DateTime DeliveredAt) : ShipmentStatus;
7public record class Cancelled(string Reason) : ShipmentStatus;

Because the compiler knows every derived type, a switch expression doesn't need a default branch:

csharp
1string Describe(ShipmentStatus status) => status switch
2{
3    Pending pending => $"Pending since {pending.CreatedAt:g}",
4    Dispatched dispatched => $"Dispatched with {dispatched.Carrier}",
5    InTransit inTransit => $"In transit, tracking {inTransit.TrackingNumber}",
6    Delivered delivered => $"Delivered at {delivered.DeliveredAt:g}",
7    Cancelled cancelled => $"Cancelled: {cancelled.Reason}"
8};

Code in another assembly can't add new statuses:

csharp
1// In a consumer assembly
2public record class Returned(DateTime ReturnedAt) : ShipmentStatus;
3// ERROR: 'ShipmentStatus' is a closed class and cannot be derived outside its assembly

Rules for closed classes:

• A closed class is implicitly abstract
• It can't be combined with sealed, static, or an explicit abstract modifier
• Derivation isn't transitive: a non-closed child of a closed class can still be extended in other assemblies

System.Text.Json can also infer the derived types of a closed hierarchy for polymorphic serialization:

csharp
1[JsonPolymorphic(InferClosedTypePolymorphism = true)]
2public closed record class ShipmentStatus;

You no longer need a [JsonDerivedType] attribute for every derived type.

When to use which:

• Union types - when the cases are unrelated types (int or string, CreditCard or PayPal)
• Closed hierarchies - when the cases share a base type and common data

C# 12 introduced collection expressions with the [...] syntax. But you couldn't pass arguments to the collection's constructor, like a capacity or a comparer.

C# 15 fixes this with a with(...) element as the first element of a collection expression:

csharp
1string[] skus = ["SKU-001", "SKU-002", "SKU-003"];
2
3// Pass capacity to the List<T> constructor
4List<string> allSkus = [with(capacity: skus.Length * 2), .. skus];
5
6// Pass a comparer to the HashSet<T> constructor
7HashSet<string> uniqueSkus = [with(StringComparer.OrdinalIgnoreCase), "sku-001", "SKU-001", "Sku-001"];
8// uniqueSkus contains only one element

Previously, you had to choose between the short collection expression syntax and a configured collection. Now you can have both.

C# 14 introduced extension members: extension properties and static extension members.

C# 15 adds extension indexers. You declare them in an extension block, just like other extension members:

csharp
1public static class ShipmentExtensions
2{
3    extension(Shipment shipment)
4    {
5        public ShipmentItem? this[string sku] =>
6            shipment.Items.FirstOrDefault(item => item.Sku == sku);
7    }
8}

Now you can index into a shipment by product SKU as if the indexer was declared on the Shipment class:

csharp
1var item = shipment["SKU-001"];
2
3if (item is not null)
4{
5    Console.WriteLine($"{item.Sku}: {item.Quantity} pcs");
6}

Because indexers are always instance members, the extension block must name its receiver parameter (shipment in this example).

When you work with nested loops, exiting the outer loop from the inner one has always been awkward.

You had to use a Boolean flag:

csharp
1var foundInvalidItem = false;
2
3foreach (var order in orders)
4{
5    foreach (var item in order.Items)
6    {
7        if (item.Quantity <= 0)
8        {
9            foundInvalidItem = true;
10            break;
11        }
12    }
13
14    if (foundInvalidItem)
15    {
16        break;
17    }
18}

Or a goto statement, which is meh.

In C# 15, break and continue can name a label on an enclosing loop:

csharp
1outer: foreach (var order in orders)
2{
3    foreach (var item in order.Items)
4    {
5        if (item.IsBackordered)
6        {
7            // Skip the whole order and move to the next one
8            continue outer;
9        }
10
11        if (item.Quantity <= 0)
12        {
13            // Stop processing all orders
14            break outer;
15        }
16    }
17
18    await ShipAsync(order);
19}

Place the label directly on the loop it identifies. Without a label, break and continue keep their original behavior and target the innermost loop.

For the first time, it might look weird. But believe me, it's a good trade-off that doesn't hurt code readability and is not the same as goto.

The new IDE0410 analyzer finds Boolean flag and goto patterns that a labeled jump can replace.

You can see the complete list of new features in C# 15 here.

.NET 10 added LeftJoin and RightJoin to LINQ, but you still had to provide a result selector:

csharp
1// .NET 10
2var orderShipments = orders.LeftJoin(
3    shipments,
4    order => order.Id,
5    shipment => shipment.OrderId,
6    (order, shipment) => new { Order = order, Shipment = shipment });

.NET 11 adds overloads that return tuples directly. You can deconstruct them in a foreach loop:

csharp
1var orderShipments = orders.LeftJoin(
2    shipments,
3    order => order.Id,
4    shipment => shipment.OrderId);
5
6foreach (var (order, shipment) in orderShipments)
7{
8    Console.WriteLine($"{order.Number}: {shipment?.Number ?? "not shipped yet"}");
9}

.NET 11 also adds a new FullJoin operator. It returns all elements from both sequences and pairs them where the keys match:

csharp
1var report = orders.FullJoin(
2    shipments,
3    order => order.Id,
4    shipment => shipment.OrderId);
5
6foreach (var (order, shipment) in report)
7{
8    var orderNumber = order?.Number ?? "(no order)";
9    var shipmentNumber = shipment?.Number ?? "(no shipment)";
10
11    Console.WriteLine($"{orderNumber} -> {shipmentNumber}");
12}

I'd reach for this in reconciliation reports, where you need to find orders without shipments and shipments without orders in a single pass.

The classic Join and GroupJoin operators also get tuple-returning overloads with an optional IEqualityComparer<T>:

csharp
1var orderItems = orders.Join(items, order => order.Id, item => item.OrderId);
2
3foreach (var (order, item) in orderItems)
4{
5    Console.WriteLine($"{order.Number}: {item.Sku}");
6}

All these operators work with Enumerable, Queryable, and AsyncEnumerable.

Running an external process and reading its output has always required a lot of setup:

csharp
1// Before .NET 11
2var startInfo = new ProcessStartInfo("git", "status --porcelain")
3{
4    RedirectStandardOutput = true,
5    RedirectStandardError = true,
6    UseShellExecute = false
7};
8
9using var process = Process.Start(startInfo)!;
10var output = await process.StandardOutput.ReadToEndAsync();
11var error = await process.StandardError.ReadToEndAsync();
12await process.WaitForExitAsync();

.NET 11 does this in a single call:

csharp
1ProcessTextOutput result = await Process.RunAndCaptureTextAsync(
2    "git", ["status", "--porcelain"]);
3
4Console.WriteLine(result.StandardOutput);
5Console.WriteLine($"Exit code: {result.ExitStatus.ExitCode}");

RunAndCaptureTextAsync starts the process, captures stdout and stderr, and waits for the exit code.

This pairs nicely with file-based apps, where you often write scripts that call git, docker, or kubectl.

The Process class gets more helpers as well:

• Process.RunAsync runs a process and returns its exit status
• Process.StartAndForget starts a process that you don't intend to wait for
• Process.TryGetProcessById looks up a process without throwing an exception

JSON Lines (JSONL) is a format where each line is a separate JSON value. It's popular for data exports and AI datasets, because you can process it line by line without loading the whole file.

JsonSerializer.SerializeAsyncEnumerable now writes JSON Lines when you set topLevelValues: true:

csharp
1public record OrderExport(string Number, string CustomerName, decimal Amount);
2
3await using var file = File.Create("orders.jsonl");
4
5await JsonSerializer.SerializeAsyncEnumerable(
6    file,
7    GetOrdersAsync(),
8    topLevelValues: true);

The output looks like this:

json
1{"Number":"ORD-001","CustomerName":"Alice","Amount":99.99}
2{"Number":"ORD-002","CustomerName":"Bob","Amount":250.00}
3{"Number":"ORD-003","CustomerName":"Charlie","Amount":15.50}

The serializer writes each value compactly, followed by a line feed. It streams data from IAsyncEnumerable<T>, so you can export millions of rows from a database without keeping them all in memory.

You can see the complete list of library changes in .NET 11 here.

ASP .NET Core 10 added built-in validation for Minimal APIs. But validation was synchronous, so you couldn't check the database inside a validation attribute without blocking a thread.

.NET 11 adds async validation with the new AsyncValidationAttribute and IAsyncValidatableObject types.

Here's an attribute that checks that an order number is unique:

csharp
1public sealed class UniqueOrderNumberAttribute : AsyncValidationAttribute
2{
3    protected override ValidationResult? IsValid(object? value, ValidationContext context) =>
4        throw new InvalidOperationException("Validate this attribute with IsValidAsync.");
5
6    protected override async Task<ValidationResult?> IsValidAsync(
7        object? value,
8        ValidationContext context,
9        CancellationToken cancellationToken)
10    {
11        var dbContext = context.GetRequiredService<OrdersDbContext>();
12
13        if (value is string number &&
14            await dbContext.Orders.AnyAsync(o => o.Number == number, cancellationToken))
15        {
16            return new ValidationResult($"Order {number} already exists.");
17        }
18
19        return ValidationResult.Success;
20    }
21}

You derive from AsyncValidationAttribute and implement IsValidAsync. The synchronous IsValid method is abstract too, so you throw from it when the attribute only validates asynchronously.

Apply the attribute like any built-in validation attribute:

csharp
1public record CreateOrderRequest(
2    [Required, UniqueOrderNumber] string Number,
3    [Required] string CustomerName,
4    [Range(1, 1_000_000)] decimal Amount);
5
6builder.Services.AddValidation();
7
8app.MapPost("/orders", (CreateOrderRequest request) =>
9{
10    // The request is already validated here
11    return Results.Ok(request);
12});

The framework validates the request before your endpoint runs. When validation fails, it returns a 400 Bad Request with the validation errors.

For rules that span several properties, implement IAsyncValidatableObject and return results as an IAsyncEnumerable<ValidationResult>.

Validators run concurrently where possible: async attributes on the same property start together, and collection items validate in parallel.

Note: The same async validation works for Microsoft.Extensions.Options through the new IAsyncStartupValidator.

Validation messages and display names can now be localized without a separate package.

Call AddLocalization before AddValidation, and localization turns on automatically:

csharp
1builder.Services.AddLocalization();
2builder.Services.AddValidation();

Use resource keys in your validation attributes:

csharp
1[ValidatableType]
2public class CustomerModel
3{
4    [Display(Name = "CustomerName")]          // resource key for the display name
5    [Required(ErrorMessage = "NameRequired")] // resource key for the message
6    public string? Name { get; set; }
7}

You don't have to use resource files. If you register your own IStringLocalizerFactory, validation messages come from your store, for example a database:

csharp
1builder.Services.AddSingleton<IStringLocalizerFactory, DbStringLocalizerFactory>();
2builder.Services.AddValidation();

The same rules work for Minimal APIs and Blazor, so a message is translated the same way wherever the model is used.

Until now, you needed the OpenTelemetry.Instrumentation.AspNetCore package to get proper HTTP traces from ASP .NET Core.

In .NET 11, ASP .NET Core adds OpenTelemetry attributes to its HTTP server activity natively. You only need to subscribe to the Microsoft.AspNetCore activity source:

csharp
1builder.Services.AddOpenTelemetry()
2    .WithTracing(tracing => tracing
3        .AddSource("Microsoft.AspNetCore")
4        .AddOtlpExporter());

I only wish we had a constant for this.

ASP .NET Core 10 made OpenAPI 3.1 the default. ASP .NET Core 11 moves to OpenAPI 3.2.

If your tools don't support OpenAPI 3.2 yet, you can switch back:

csharp
1builder.Services.AddOpenApi(options =>
2{
3    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_1;
4});

OpenAPI 3.2 can describe streaming responses. Endpoints that return Server-Sent Events with SseItem<T> now get a proper schema for each event:

csharp
1app.MapGet("/stocks/stream", (StockService stockService, CancellationToken ct) =>
2    TypedResults.ServerSentEvents(GetStockPricesAsync(stockService, ct)));
3
4static async IAsyncEnumerable<SseItem<StockPriceEvent>> GetStockPricesAsync(
5    StockService stockService,
6    [EnumeratorCancellation] CancellationToken ct = default)
7{
8    await foreach (var price in stockService.GenerateStockPrices(ct))
9    {
10        yield return new SseItem<StockPriceEvent>(price) { EventId = price.Id };
11    }
12}

The generated document describes the payload with itemSchema, instead of a plain string:

yaml
1responses:
2  '200':
3    description: OK
4    content:
5      text/event-stream:
6        itemSchema:
7          type: object
8          required: [data]
9          properties:
10            data:
11              $ref: '#/components/schemas/StockPriceEvent'
12            event: { type: string }
13            id: { type: string }

Tools that read your OpenAPI document now see the real shape of each event.

Note: Return the stream through TypedResults.ServerSentEvents. A handler that returns IAsyncEnumerable<SseItem<T>> directly is serialized as JSON instead of SSE.

OpenAPI also gets support for binary file responses (type: string, format: binary), HTTP QUERY operations, and [Obsolete] endpoints marked as deprecated.

The Model Context Protocol (MCP) is an open standard that AI tools like Claude Code, Codex, GitHub Copilot and Visual Studio use to call external tools and data.

The mcpserver project template now ships with the .NET SDK, so you don't need to install a separate package:

bash
1dotnet new mcpserver -o Shipments.McpServer

The generated project uses the official C# MCP SDK and includes a sample tool. Program.cs registers the MCP server and discovers tools in your assembly:

csharp
1builder.Services
2    .AddMcpServer()
3    .WithStdioServerTransport()
4    .WithToolsFromAssembly();

A tool is a method marked with attributes:

csharp
1[McpServerToolType]
2public static class ShipmentTools
3{
4    [McpServerTool, Description("Returns the estimated delivery date for a shipment.")]
5    public static string GetDeliveryEstimate(string trackingNumber) =>
6        $"Shipment {trackingNumber} arrives on {DateTime.UtcNow.AddDays(3):yyyy-MM-dd}";
7}

An AI agent can now call GetDeliveryEstimate when a user asks about a shipment.

You can see the complete list of ASP .NET Core 11 features here.

EF Core 11 generates better SQL when you include reference navigations. This change speeds up existing queries without any code changes.

Consider this split query:

csharp
1var orders = await context.Orders
2    .Include(o => o.Customer)
3    .Include(o => o.Items)
4    .AsSplitQuery()
5    .ToListAsync();

Before EF Core 11, the query for Items contained a join to Customers that nobody needed:

sql
1-- Before EF Core 11
2SELECT [i].[Id], [i].[OrderId], [i].[Sku], [o].[Id], [c].[Id]
3FROM [Orders] AS [o]
4INNER JOIN [Customers] AS [c] ON [o].[CustomerId] = [c].[Id]
5INNER JOIN [OrderItems] AS [i] ON [o].[Id] = [i].[OrderId]
6ORDER BY [o].[Id], [c].[Id]

EF Core 11 removes the unneeded join:

sql
1-- EF Core 11
2SELECT [i].[Id], [i].[OrderId], [i].[Sku], [o].[Id]
3FROM [Orders] AS [o]
4INNER JOIN [OrderItems] AS [i] ON [o].[Id] = [i].[OrderId]
5ORDER BY [o].[Id]

EF also stops adding redundant reference navigation keys to ORDER BY in single queries. The order's key already identifies the row, so the customer's key isn't needed.

The EF team measured a 29% improvement for a common split query and a 22% improvement for a single query.

If you want to learn more about query performance, check out my step-by-step guide to EF Core optimization.

EF Core 10 added LeftJoin and RightJoin. EF Core 11 translates the new .NET 11 FullJoin operator to SQL FULL JOIN:

csharp
1var results = await context.Orders
2    .FullJoin(
3        context.Shipments,
4        order => order.Id,
5        shipment => shipment.OrderId,
6        (order, shipment) => new
7        {
8            OrderNumber = order.Number,
9            ShipmentNumber = shipment.Number
10        })
11    .ToListAsync();

This generates the following SQL:

sql
1SELECT [o].[Number] AS [OrderNumber], [s].[Number] AS [ShipmentNumber]
2FROM [Orders] AS [o]
3FULL JOIN [Shipments] AS [s] ON [o].[Id] = [s].[OrderId]

Before EF Core 11, you had to write raw SQL or combine two left joins with Union to get the same result.

EF Core 10 made complex types a first-class alternative to owned entities. EF Core 11 removes several of their limitations.

Complex Types with TPT and TPC Inheritance

You can now use complex types and JSON columns on entities with TPT (table-per-type) and TPC (table-per-concrete-type) inheritance:

csharp
1public abstract class Product
2{
3    public int Id { get; set; }
4    public string Name { get; set; } = string.Empty;
5    public required ProductDetails Details { get; set; }
6}
7
8public class PhysicalProduct : Product
9{
10    public decimal WeightKg { get; set; }
11}
12
13public class DigitalProduct : Product
14{
15    public string DownloadUrl { get; set; } = string.Empty;
16}
17
18[ComplexType]
19public class ProductDetails
20{
21    public string? Description { get; set; }
22    public string? Manufacturer { get; set; }
23}

csharp
1modelBuilder.Entity<Product>()
2    .UseTptMappingStrategy()
3    .ComplexProperty(p => p.Details, b => b.ToJson());

Keys and Indexes on Complex Type Properties

Keys and indexes can now use properties inside complex types:

csharp
1modelBuilder.Entity<Customer>()
2    .HasIndex(c => c.Address.PostalCode);

For JSON columns, you can index paths inside complex collections. Use [] to index all elements:

csharp
1modelBuilder.Entity<Order>()
2    .ComplexCollection(o => o.Items, b => b.ToJson());
3
4modelBuilder.Entity<Order>()
5    .HasIndex("Items[].Sku");

Simpler Configuration

Previously, you had to call ComplexProperty first to configure a property of a complex type:

csharp
1modelBuilder.Entity<Product>()
2    .ComplexProperty(p => p.Details)
3    .Property(d => d.Description)
4    .HasMaxLength(500);

Now you can reach the nested property directly:

csharp
1modelBuilder.Entity<Product>()
2    .Property(p => p.Details.Description)
3    .HasMaxLength(500);

The EF team also fixed a long list of complex-type bugs, so you can migrate from owned entities with greater confidence.

EF Core 11 translates MaxBy and MinBy, and their async versions. They return the whole element with the largest or smallest key. Max and Min only return the key itself.

Here's how to find the customer with the most orders:

csharp
1var topCustomer = await context.Customers
2    .MaxByAsync(c => c.Orders.Count());

This translates to the following SQL:

sql
1SELECT TOP(1) [c].[Id], [c].[Name]
2FROM [Customers] AS [c]
3ORDER BY (
4    SELECT COUNT(*)
5    FROM [Orders] AS [o]
6    WHERE [c].[Id] = [o].[CustomerId]) DESC

Previously, you had to write OrderByDescending(...).FirstOrDefaultAsync() for the same result.

EF Core 10 added EF.Functions.VectorDistance() for exact vector search in SQL Server. Exact search compares the query against every row, which gets slow on large tables.

EF Core 11 supports vector indexes and approximate search with SQL Server 2025 VECTOR_SEARCH():

csharp
1modelBuilder.Entity<Product>()
2    .HasVectorIndex(p => p.Embedding, "cosine");

csharp
1var similarProducts = await context.Products
2    .VectorSearch(p => p.Embedding, queryEmbedding, "cosine")
3    .OrderBy(r => r.Distance)
4    .Take(5)
5    .WithApproximate()
6    .ToListAsync();

WithApproximate() tells SQL Server to use the vector index for approximate nearest neighbor (ANN) search. VectorSearch() returns VectorSearchResult<TEntity>, so you get the distance alongside the entity.

Vector columns are also no longer loaded by default when you query entities. Vectors can contain thousands of numbers, and this change alone made a benchmark 9x faster locally and 22x faster against Azure SQL.

EF Core 11 also supports SQL Server full-text table-valued functions, which return a relevance rank:

csharp
1var results = await context.Products
2    .FreeTextTable("wireless headphones", p => p.Name)
3    .Select(r => new { Product = r.Value, r.Rank })
4    .OrderByDescending(r => r.Rank)
5    .ToListAsync();

You can combine full-text search and vector search with FullJoin to build hybrid search. Full-text search finds exact word matches, vector search finds results with a similar meaning, and you merge both rankings. You can find the complete example in the EF Core documentation.

Note: VECTOR_SEARCH() and vector indexes are still experimental in SQL Server, and the EF Core APIs may change.

EF Core 11 makes migrations easier to manage, especially in teams.

Create and Apply a Migration in One Step

The dotnet ef database update command has a new --add option. It creates a migration, compiles it with Roslyn, and applies it in one step:

bash
1dotnet ef database update AddShipmentTracking --add

The migration files are still saved to disk for source control.

Configuration File for dotnet ef

If you work with a multi-project solution, you know the pain of typing --project and --startup-project with every command.

EF Core 11 reads default options from a .config/dotnet-ef.json file:

json
1{
2  "project": "src/Shipments.Infrastructure",
3  "startupProject": "src/Shipments.Api",
4  "context": "ShipmentsDbContext"
5}

Now dotnet ef migrations add AddCarrier works without extra options. Options you pass on the command line still win.

Run Commands for All DbContexts

If your project has multiple DbContext types, you can run several commands for all of them at once with --context "*":

bash
1dotnet ef database update --context "*"
2dotnet ef migrations list --context "*"

This is great for modular monoliths, where each module has its own DbContext.

Detect Diverged Migrations

When two developers create migrations on separate branches, the migration history can split without anyone noticing.

EF Core 11 records the latest migration ID in the model snapshot. If two branches both add migrations, they both change this value, and Git reports a merge conflict. The conflict tells your team to fix the migrations before they reach the database.

The dotnet ef migrations remove command also gets --connection and --offline options, so you can remove a migration without a configured database connection.

You can see the complete list of EF Core 11 features here.

Check these changes before you upgrade:

• New minimum CPU requirements: x86/x64 now requires x86-64-v2, and Windows on Arm64 requires the LSE instruction set. .NET 11 won't start on older hardware (details).
• BackgroundService failures: IHost.RunAsync and IHost.StopAsync now throw when a BackgroundService fails.
• Async options validation: Reading async-validated options synchronously throws an exception.
• Saturating conversions: float and double conversions to small integer types now saturate to the type bounds instead of wrapping.
• Stricter archives: Reading ZIP entries validates CRC32, and reading TAR archives validates header checksums. Corrupted files now throw InvalidDataException.
• OpenAPI 3.2: Generated documents target OpenAPI 3.2 by default, and Microsoft.OpenApi 3.x has breaking API changes.
• EF Core SQL Server compatibility level: UseSqlServer now defaults to compatibility level 160 (SQL Server 2022) (details).
• EF Core and Microsoft.Data.SqlClient 7.0: EF Core 11 updates the SQL Server driver to a new major version.
• EF Core migrations: EF Core now throws by default when no migrations are found.
• EF Core Cosmos DB: The provider switches from Newtonsoft.Json to System.Text.Json, removes the __jObject shadow property, and no longer preserves unmapped JSON properties.

You can see the complete list of breaking changes in .NET 11 and EF Core 11.

.NET 11 and C# 15 change how we model data and how async code runs.

• Union types and closed hierarchies let the compiler check that you handle every case. Missing cases become build warnings instead of runtime bugs.
• Runtime Async gives you cleaner stack traces and faster async code, and the .NET libraries already use it.
• C# 15 quality-of-life features like collection expression arguments, extension indexers, and labeled break and continue remove small but common friction.
• ASP .NET Core 11 adds async validation, built-in validation localization, native OpenTelemetry tracing, and OpenAPI 3.2.
• EF Core 11 generates faster SQL for includes, supports FullJoin and MaxBy, and makes migrations easier to manage in a team.

.NET 11 is an STS release with 24 months of support. If you're on .NET 10 LTS, there is no rush to migrate production apps. But union types and Runtime Async are worth upgrading for sure (I will be migrating my projects in November and December).

Additional resources for .NET 11:

• Breaking changes in .NET 11
• What's New in the .NET 11 SDK
• What's New in the .NET 11 runtime
• What's New in .NET libraries for .NET 11
• What's New in ASP .NET Core in .NET 11
• What's New in EF Core 11
• What's New in C# 15
• Performance Improvements in .NET 11
• What's New in Aspire

Are you excited about .NET 11? Do you plan to upgrade your projects to this version?

Leave a comment below and let me know.

Hope you find this newsletter useful. See you next time.