.NET 11 RC 1 STS RC

Day 1 was the adoption story: .NET 10 is LTS and ready now. Day 2 is a decision story: whether .NET 11 is worth taking before the next LTS.

Runtime Async .NET 11

Runtime-native async is the headline runtime change: the async state machine moves out of compiler-generated types and into the runtime. Your async/await source does not change at all.

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <!-- Required on RC 1. Without it you get the classic compiler state machine. -->
  <Features>$(Features);runtime-async=on</Features>
</PropertyGroup>

The difference is directly observable by reflection — count the types in your own assembly that implement IAsyncStateMachine:

state machines: 4
Deep3 has AsyncStateMachineAttribute: True

state machines: 0
Deep3 has AsyncStateMachineAttribute: False

Raised minimum hardware requirements

.NET 11 raises baseline instruction-set requirements for x86/x64 and Arm64. That is a runtime improvement, but it is also a real deployment question.

JIT and SIMD: more work reaches the hardware

The runtime work is not only async. .NET 11 also broadens the vector surface and the hardware paths the JIT can use.

SDK and tooling wins worth showing

These are the small things that make a workshop feel current: faster demos, less project scaffolding, and better defaults.

dotnet run -e FeatureFlag=RuntimeAsync -e Customer=workshop

# File-based apps can now include another file.
dotnet run app.cs

Runtime Async changes the compiled shape .NET 11

The useful demo is not a prettier stack trace. It is the disappearance of compiler-generated async artefacts.

runtime : .NET 11.0.0-rc.1.26425.128
result  : 1
state machines: 4
   <Deep1>d__0
   <Deep2>d__1
   <Deep3>d__2
   <Main>d__3
Deep3 has AsyncStateMachineAttribute: True

runtime : .NET 11.0.0-rc.1.26425.128
result  : 1
state machines: 0
Deep3 has AsyncStateMachineAttribute: False

Can you tell whether a dependency was compiled runtime-async?

Yes, but treat it as an assembly-inspection question, not a package-version question. Look for generated state-machine types and async attributes in the assembly you actually deployed.

using System.Reflection;
using System.Runtime.CompilerServices;

static bool LooksCompilerAsync(Assembly assembly) =>
    assembly.GetTypes().Any(t =>
        typeof(IAsyncStateMachine).IsAssignableFrom(t));

static bool HasAsyncAttribute(MethodInfo method) =>
    method.GetCustomAttribute<AsyncStateMachineAttribute>() is not null;

What runtime async means for library authors

Your public async API shape stays boring. The implementation artefacts underneath it are the part that changes.

Profilers and diagnostics need a representation check

Runtime async is a good thing, but it can invalidate tooling assumptions that were never part of the source contract.

How to evaluate runtime async on your own workload

Do not turn the feature into a microbenchmark contest. Test the service shape that actually pays your cloud bill.

1. Pick one async-heavy path. HTTP fan-out, database access, queue processing and SDK clients are better candidates than CPU-only loops.
2. Build two artefacts from the same commit. Default net11.0 and the same project with the runtime-async feature switch.
3. Measure the same load. Capture throughput, latency percentiles, allocations and GC activity. Do not paste invented numbers into the deck.
4. Compare diagnostics. Check traces, profiler grouping, coverage and failure triage before calling the result production-ready.

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <Features>$(Features);runtime-async=on</Features>
</PropertyGroup>

AOT and trimming: treat warnings as design feedback

.NET 11 keeps pushing deployment towards smaller, earlier-validated artefacts. That only helps if teams stop treating trim and AOT warnings as noise.

Should runtime changes move you off .NET 10 LTS?

The honest answer is “sometimes”. .NET 10 is the safe LTS baseline; .NET 11 is the STS decision release.

Narrowing float conversions now saturate

The highest-impact silent behaviour change we found in .NET 11. No warning, no analyzer, no compatibility switch — the same expression returns a different number.

// values returned from [MethodImpl(NoInlining)] methods so nothing is constant-folded
double d300 = Double300();   // 300.0
double dNeg = NegOne();      // -1.0

Console.WriteLine((byte)d300);
Console.WriteLine((byte)dNeg);

Lab 05 — Runtime Async 20 min

Make async failure boring to diagnose.

cd labs/Day2/05-RuntimeAsync/start
dotnet run

The starter project deliberately throws from deep inside a chain of async calls. Your tasks:

1. Run it on default net11.0 and count the types in your own assembly that implement IAsyncStateMachine.
2. Add <Features>$(Features);runtime-async=on</Features> and count again.
3. Capture the stack trace in both configurations and on net10.0, and compare them honestly — you should find no difference at all.
4. Explain why none of the application async/await source code changed, and where the cost saving actually comes from.

C# 15 C# 15

C# 14 let you add members to types you do not own. C# 15 turns to modelling: closed choices, exhaustive switches, and fewer ceremony patterns around collections, loops and low-level code.

union types C# 15

A union models a value that is exactly one of a fixed set of case types. The cases do not need to share a base class or an interface.

public sealed record Cat(string Name);
public sealed record Dog(string Name);
public sealed record Bird(string Name);

public union Pet(Cat, Dog, Bird);

Pet pet = new Dog("Rex");       // implicit conversion from a case type

string message = pet switch
{
    Cat cat => $"cat {cat.Name}",
    Dog dog => $"dog {dog.Name}",
    Bird bird => $"bird {bird.Name}"
};

union: dog Rex

The compiler knows the complete case set, so the switch is exhaustive without a default arm. That turns "did we handle every result?" from a code-review habit into a compile-time check — though only a warning-level one until you promote CS8509, which we come back to shortly.

Use this for "one of N" results: success, validation failure, not found. It avoids an inheritance hierarchy you only created for matching, a bag of nullable properties, or expected control flow expressed as exceptions. At runtime, unions are backed by .NET 11 support including UnionAttribute and IUnion.

closed hierarchies C# 15

closed is for the other modelling case: you own the hierarchy and want shared members or behaviour, but you still want the compiler to know the set of descendants.

public closed class Discount
{
    public required string Code { get; init; }
}

public sealed class Percentage(decimal Rate) : Discount;
public sealed class FixedAmount(decimal Amount) : Discount;

string label = discount switch
{
    Percentage p => $"{p.Rate:P1} off",
    FixedAmount f => $"{f.Amount:C} off"
};

closed: 42.5% open

Union or closed hierarchy?

Both features buy exhaustive matching. Choose based on ownership and whether the cases need shared behaviour.

<!-- Without this, "exhaustive matching" is a suggestion, not a guarantee. -->
<PropertyGroup>
  <WarningsAsErrors>$(WarningsAsErrors);CS8509</WarningsAsErrors>
</PropertyGroup>

Collection expression arguments C# 15

Collection expressions are concise, but before C# 15 they could not pass constructor arguments such as capacity or a comparer. with(...) fills that gap.

int[] values = [1, 2, 3];

List<int> list = [with(capacity: 4), .. values];

HashSet<string> names = [
    with(StringComparer.OrdinalIgnoreCase),
    "Hello",
    "hello"
];

list.Count    = 3
list.Capacity = 4
names.Count   = 1

extension indexers C# 15

C# 14 introduced extension blocks. C# 15 lets those blocks declare indexers too, which removes another reason to invent helper methods on types you do not own.

public static class EnumerableIndexers
{
    extension(IEnumerable<int> numbers)
    {
        public int this[int index] => numbers.ElementAt(index);
    }
}

IEnumerable<int> values = [1, 2, 3, 4];
Console.WriteLine(values[2]);

extension indexer: 3

Labeled break and continue

Nested loops often grow boolean flags or tiny goto exits. C# 15 lets break and continue target a specific enclosing loop by label.

Customer[] customers =
[
    new Customer("A", [new Order(false, "a1"), new Order(true, "a2"), new Order(false, "a3")]),
    new Customer("B", [new Order(false, "b1")]),
];

outer:
foreach (var customer in customers)
{
    Console.WriteLine(customer.Name);

    foreach (var order in customer.Orders)
    {
        if (order.IsFraudulent)
            continue outer;

        Process(order);
    }
}

A
  processed a1
B
  processed b1

safe, unsafe and pointer relaxations

The memory-safety work is deliberately multi-release. It narrows where unsafe is needed, but it does not make pointer code safe — and on RC 1 it is not part of C# 15.

<PropertyGroup>
  <TargetFramework>net11.0</TargetFramework>
  <LangVersion>preview</LangVersion>
  <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
</PropertyGroup>

Exhaustive does not mean a case is present

C# 15 can prove that every declared case has an arm. It cannot prove that the value you received is one of those cases.

static string Describe(Pet pet) => pet switch
{
    Cat c => $"cat {c.Name}",
    Dog d => $"dog {d.Name}",
    Bird b => $"bird {b.Name}",
    _ => "UNINITIALISED"
};

What a union actually is

The syntax looks like a discriminated union. The RC 1 runtime shape is simpler: a value type wrapper around an object payload.

IsValueType  : True
BaseType     : ValueType
iface        : System.Runtime.CompilerServices.IUnion
attribute    : System.Runtime.CompilerServices.UnionAttribute
member       : Property System.Object Value
member       : Constructor Void .ctor(Cat) / .ctor(Dog) / .ctor(Bird)

==, ToString() and identity traps

A union containing records does not behave like the record surface you are used to reaching for.

Pet a = new Cat("Tom");
Pet b = new Cat("Tom");

// a == b    // CS0019
bool same = a.Equals(b);

Getting data back out of a union

The conversion into a union is implicit. The conversion out is deliberately not a cast.

Pet pet = new Dog("Rex");

var dog = (Dog)pet; // CS0030

string name = pet switch
{
    Dog d => d.Name,
    Cat c => c.Name,
    Bird b => b.Name,
    _ => "unknown"
};

Union allocation: free until value types enter

The wrapper itself is cheap. The payload type decides whether you introduced an allocation.

Generic, nested and value-type unions work

The useful subset in RC 1 is broader than just a few record classes in a demo.

public union Result<T>(T, Err);     // generic
public union Num(int, double);      // value-type cases
public union Outer(Ok, Num);        // union as a case

1 generic ok : 42
2 int case   : int 42
2 dbl case   : double 3.5
3 nested     : num 7

Modelling decision table

Use the feature that matches the ownership and evolution shape of the domain, not the one with the newest keyword.

Migrating an existing hierarchy to closed

The mechanical edit is small. The real work is checking whether the hierarchy was accidentally extensible.

public abstract class Discount
{
    public required string Code { get; init; }
}

public sealed class Percentage : Discount;
public sealed class FixedAmount : Discount;

public closed class Discount
{
    public required string Code { get; init; }
}

public sealed class Percentage : Discount;
public sealed class FixedAmount : Discount;

Nullability does not close the absent-state hole

Nullable reference types and exhaustive matching answer different questions. You want both.

static string Label(Discount? discount) => discount switch
{
    null => "missing discount",
    Percentage p => $"{p.Rate:P1} off",
    FixedAmount f => $"{f.Amount:C} off"
};

What we would adopt first

Treat C# 15 as a modelling upgrade, not a search-and-replace exercise.

Unions stop at the expression-tree boundary

The single most important constraint for this room: a union conversion cannot appear in an expression tree, so a union cannot be projected inside an EF Core query.

public record Dog(string Name);
public record Cat(string Name);
public union Pet(Dog, Cat);

Expression<Func<Dog, Pet>> f = d => d;   // implicit Dog -> Pet conversion

error CS9369: An expression tree may not contain a union conversion.

// Materialise first, then model.
var rows = await db.Pets
    .Where(p => p.OwnerId == ownerId)
    .ToListAsync();

IReadOnlyList<Pet> pets = rows
    .Select(r => r.Kind == "dog" ? (Pet)new Dog(r.Name) : new Cat(r.Name))
    .ToList();

A method named with vanishes from a collection expression

C# 15 collection expressions take arguments. That gives one identifier a new meaning in one position — and the element you wrote disappears without a diagnostic.

static string with(int n) => "W" + n;

List<string> a = [with(3), "a"];    // what happens here?
List<string> b = [@with(3), "a"];   // escaped

plain    with(3): Count=1, Capacity=3, Items=[a]
escaped @with(3): Count=2, Capacity=2, Items=[W3, a]

Lab 06 — Unions and closed hierarchies 40 min

Model one domain result two ways, then let the compiler police the future.

cd labs/Day2/06-CSharp15-Unions/start
dotnet test

Your tasks:

1. Model the starter domain result as a union.
2. Model the same choices as a closed hierarchy.
3. Use exhaustive switch expressions with no default arm.
4. Add a new case and watch every incomplete switch fail to compile.
5. Decide which model better fits the domain and write down why.

.NET 11 libraries .NET 11

The library story is broad rather than single-theme: JSON catches up with language features, LINQ gains missing joins, compression expands, and validation finally has an async path.

System.Text.Json: naming, streams and unions

System.Text.Json continues to move from "fast serializer" towards "default platform JSON stack". In .NET 11, the most teachable changes are contract control and streaming shapes.

var options = new JsonSerializerOptions
{
    PropertyNamingPolicy = JsonNamingPolicy.PascalCase
};

string json = JsonSerializer.Serialize(new Person("Ada"), options);

STJ PascalCase: {"FirstName":"Ada"}

• JsonNamingPolicy.PascalCase for built-in PascalCase output.
• Per-member naming policy overrides and type-level ignore conditions.
• NDJSON and top-level SerializeAsyncEnumerable.
• PipeWriter targets and Utf8JsonWriter.Reset.
• C# 15 union serialization through JsonUnionTypeStructuralClassifier.

Serialize   -> {"Isbn":"978-0","Title":"Compilers"}     // fine
Deserialize -> JsonException: JSON value type 'Object' is ambiguous for
               union type 'CatalogItem' because multiple case types can use
               this value type. Specify a custom type classifier to support
               deserialization.

var options = new JsonSerializerOptions();
options.TypeClassifiers.Add(new JsonUnionTypeStructuralClassifier());

The JsonUnionTypeStructuralClassifier cannot classify union type 'Shape'
because the case type 'Circle' can never be selected uniquely. The case type
'Square' recognizes every property name recognized by 'Circle' and has no
stricter required-property or unmapped-member constraints.

LINQ FullJoin and tuple joins

LINQ gains FullJoin, plus tuple-returning Join and GroupJoin, across Enumerable, Queryable and AsyncEnumerable.

FullJoin: 1/0, 2/0, 3/3, 0/4

Compression and numerics

Several .NET 11 library additions are not everyday web-app features, but they matter when you are building infrastructure or numeric libraries.

Async validation, crypto and networking

Validation finally gets an async path in the platform, and the lower-level networking and crypto surface continues to move forward.

Exact names matter .NET 11

The library surface is large enough that plausible names are a real risk. These three corrections belong on the workshop slide, not in presenter memory.

Zstandard is a family, not just a stream

Use zstd when you care about modern compression ratios and fast decompression, especially for repeated small shapes such as logs or JSON events.

IEEE 754 decimal floating point is not decimal with a new size

Decimal32, Decimal64 and Decimal128 are for interoperability with decimal floating-point formats, not a general instruction to rewrite financial code.

using System.Numerics;

Decimal128 amount = default;

Async validation is a full surface, not one helper

The important change is symmetry: object, property and value validation now have async names, including try-style variants.

IAsyncStartupValidator: startup checks can await

This is the options pipeline growing an async branch, not DataAnnotations growing a hosting feature.

Making System.Text.Json unions round-trip

The existing slide shows the asymmetry: union serialization can work while deserialization needs classification. This slide turns that into design guidance.

System.Text.Json: contract names, streams and writer reuse

Beyond unions, the .NET 11 JSON work is about removing small adapters around naming, streaming and buffer ownership.

IAsyncEnumerable<OrderEvent> events = ReadEventsAsync();
// Use JsonSerializer.SerializeAsyncEnumerable for top-level streaming output.

Cryptography in .NET 11: X25519 after the PQC conversation

Day 1 covered .NET 10 PQC: ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures, plus platform support gates. .NET 11 adds a classical key-agreement piece.

DnsResolver: DNS becomes a typed library concern

Networking code often outgrows simple host-to-address lookup. .NET 11 adds a resolver surface for code that needs more explicit DNS behaviour.

Lab 07 — Libraries in .NET 11 25 min

Connect the language and library stories in one small reconciliation flow.

cd labs/Day2/07-Libraries11/start
dotnet test

Your tasks:

1. Round-trip a C# 15 union through System.Text.Json.
2. Use PascalCase naming and verify the JSON contract.
3. Use FullJoin to reconcile two sequences.
4. Deliberately hit the default(T) ambiguity with integers.
5. Fix the projection so missing values are unambiguous.

Also know exists

HTTP body compression, connection eviction, four new zero-copy Stream types, EqualityComparer<T>.Create and generic Random overloads are all part of the broader .NET 11 library surface.

ASP.NET Core 11 RC 1

The ASP.NET Core story is practical rather than flashy: better contracts, better validation, better observability, and one breaking OpenAPI default you should hit in a lab before it hits CI.

OpenAPI 3.2 is now the default Breaking

.NET 10 generated OpenAPI 3.1 by default. ASP.NET Core 11 moves that default to OpenAPI 3.2.

using Microsoft.OpenApi;

builder.Services.AddOpenApi(o =>
    o.OpenApiVersion = OpenApiSpecVersion.OpenApi3_1);

Do not treat this as a cosmetic diff. OpenAPI documents are build artefacts, deployment inputs and external contracts.

Union result shapes and SSE documentation C# 15

C# 15 union types are not just language trivia. Minimal APIs can return a union of result shapes, and ASP.NET Core can reflect that shape into the OpenAPI document.

public union LookupResult(Ok<CustomerDto>, NotFound, ValidationProblem);

app.MapGet("/customers/{id}", Lookup);

static async Task<LookupResult> Lookup(CustomerId id, CustomerDb db)
    => await db.FindAsync(id) is { } customer
        ? TypedResults.Ok(customer.ToDto())
        : TypedResults.NotFound();

That ties directly back to module 2: unions make the endpoint contract explicit in code, then OpenAPI makes it visible to callers.

Minimal APIs grow up

The endpoint layer gets a set of small but useful pieces that remove custom plumbing from production APIs.

MCP template, tracing and compression

ASP.NET Core 11 also moves some previously specialist concerns into the standard SDK and hosting stack.

dotnet new list mcp
dotnet new mcpserver -n Customer.Tools

The upgrade changes the envelope, not the contract

The same ASP.NET Core app was built on .NET 10 and .NET 11 RC 1, then its generated OpenAPI document was diffed.

line 2    10: "openapi": "3.1.1",
          11: "openapi": "3.2.0",
line 9    server URL formatting changed

servers[].url lost its trailing slash

The second measured diff is easy to dismiss, but strict downstream tooling often treats URLs as strings, not intentions.

{
  "net10": { "servers": [{ "url": "http://localhost:5285/" }] },
  "net11": { "servers": [{ "url": "http://localhost:5035" }] }
}

The integer-or-string schema is not new

A JSON Schema type array can look like a .NET 11 novelty when you first inspect the 3.2 document. It is not.

Run the OpenAPI pipeline, not just the app

The .NET 11 app can run perfectly while the generated contract breaks a build, gateway import or partner generator.

Serve pinned and 3.2 documents side by side

You do not have to choose between blocking the upgrade and surprising every downstream consumer on day one.

using Microsoft.OpenApi;

builder.Services.AddOpenApi("v1", options =>
    options.OpenApiVersion = OpenApiSpecVersion.OpenApi3_1);

builder.Services.AddOpenApi("v32");

HTTP QUERY is finally describable in the document

Complex search requests often want safe semantics and a body. OpenAPI 3.2 gives ASP.NET Core somewhere standard to put that operation.

using Microsoft.OpenApi;

builder.Services.AddOpenApi(options =>
    options.OpenApiVersion = OpenApiSpecVersion.OpenApi3_2);

app.MapMethods("/search", ["QUERY"], (SearchRequest request) =>
    SearchService.Run(request));

OpenAPI 3.2 makes SSE payloads part of the contract

Day 1 introduced first-party Server-Sent Events. ASP.NET Core 11 adds the missing contract story for streamed event payloads.

app.MapGet("/todos/stream", (CancellationToken ct) =>
    TypedResults.ServerSentEvents(GetTodosAsync(ct)));

static async IAsyncEnumerable<SseItem<Todo>> GetTodosAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    foreach (var todo in Todos.All)
    {
        yield return new SseItem<Todo>(todo)
        {
            EventId = todo.Id.ToString()
        };
        await Task.Delay(1000, ct);
    }
}

Async validation belongs in the validation pipeline

Minimal APIs already got built-in validation in .NET 10. ASP.NET Core 11 closes the gap for rules that have to await I/O.

public sealed class UniqueEmailAttribute : AsyncValidationAttribute
{
    protected override ValidationResult? IsValid(
        object? value, ValidationContext context) =>
        throw new InvalidOperationException("Use async validation.");

    protected override async Task<ValidationResult?> IsValidAsync(
        object? value,
        ValidationContext context,
        CancellationToken cancellationToken)
    {
        var users = context.GetRequiredService<IUserService>();
        return value is string email &&
            await users.EmailExistsAsync(email, cancellationToken)
                ? new ValidationResult("Email already exists.")
                : ValidationResult.Success;
    }
}

Authentication gets more testable and more bound to TLS

ASP.NET Core 11 authentication changes are operational: fewer clock hacks in tests, and stronger binding between authenticated requests and TLS.

services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();

var tls = context.Features.Get<ITlsConnectionFeature>();
if (tls?.TryGetChannelBindingBytes(
        ChannelBindingKind.Endpoint,
        out ReadOnlyMemory<byte> cbt) == true)
{
    // Compare cbt with the authenticated token.
}

Rate limits, compression and caches get sharper edges

These are not headline APIs, but they are exactly where production traffic, clients and intermediaries meet your app.

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions
    {
        Quality = 6
    };
});

A pragmatic ASP.NET Core 11 upgrade playbook

Treat ASP.NET Core 11 as a contract and operations upgrade first. Adopt new endpoint features second.

Lab 08 — upgrade the API 25 min

This is Day 1's Lab 03 again: the same API, retargeted from net10.0 to net11.0.

cd labs/Day2/08-AspNet11-Migration/start
dotnet build

Your tasks:

1. Retarget the API project to net11.0 and build it with the RC 1 SDK.
2. Generate the OpenAPI document before and after the retarget.
3. Diff the two documents and discover the 3.1 to 3.2 change yourself.
4. Convert one endpoint to return a C# 15 union of result shapes.
5. Add an async validator and watch how the endpoint behaviour changes.

EF Core 11 Top interest

This is the module most teams come for. The through-line is simple: EF Core 10 made complex types the value-object direction; EF Core 11 makes that direction much more complete.

Complex types become complete

Complex types were introduced as the replacement direction for owned-entity value-object modelling. EF Core 11 is where they start to feel genuinely complete.

modelBuilder.Entity<Customer>()
    .ComplexProperty(c => c.Address);

modelBuilder.Entity<Customer>()
    .HasIndex(c => c.Address.Postcode);

Query translation keeps getting less surprising

Most EF Core query work is not a new headline API. It is the generated SQL getting closer to what you would have written by hand.

var newest = db.Orders
    .Where(o => o.CustomerId == customerId)
    .MaxBy(o => o.CreatedAt);

SQL Server vector, JSON and temporal work

EF Core 11 adds several SQL Server features that are strategically important, even though the hands-on labs stay on SQLite so everyone can run them locally.

Migrations get workflow features

This is not glamorous, but it is the part data teams feel every sprint.

dotnet new tool-manifest
dotnet tool install dotnet-ef
dotnet ef --help

Where the new query operators actually live EF Core 11

The most important correction is vocabulary: these are LINQ operators. EF Core 11 makes more of them database-shaped.

Full outer joins: now readable LINQ, when the engine can run it

FullJoin removes the hand-written union of left and right joins, but the generated SQL still has to be valid for your database.

var query = db.Customers.FullJoin(
    db.Orders,
    customer => customer.Id,
    order => order.CustomerId,
    (customer, order) => new
    {
        Name = customer == null ? "[no customer]" : customer.Name,
        Total = order == null ? null : order.Total
    });

SQL> SELECT "c"."Name", "o"."Total"
     FROM "Customers" AS "c"
     FULL JOIN "Orders" AS "o" ON "c"."Id" = "o"."CustomerId"
executed OK, 2 rows

MaxBy and MinBy: prove the translation

MaxBy is an immediate operator, so the result alone tells you nothing about whether the database did the work.

var newest = db.Orders
    .Where(o => o.CustomerId == 1)
    .MaxBy(o => o.CreatedAt);

var newest = db.Orders
    .Where(o => o.CustomerId == 1)
    .OrderByDescending(o => o.CreatedAt)
    .FirstOrDefault();

SQL> SELECT "o"."Id", "o"."CreatedAt", "o"."CustomerId", "o"."Total"
     FROM "Orders" AS "o"
     WHERE "o"."CustomerId" = 1
     ORDER BY "o"."CreatedAt" DESC
     LIMIT 1
result: Id=2

How to see the SQL when ToQueryString() cannot help

Use ToQueryString() for queryables. Use command logging for operators that execute immediately.

IQueryable<Order> query = db.Orders
    .Where(o => o.CustomerId == 1);

Console.WriteLine(query.ToQueryString());

optionsBuilder.LogTo(
    Console.WriteLine,
    [RelationalEventId.CommandExecuted]);

Client evaluation in 2026: fail loudly, then test the escape hatches

Modern EF Core generally refuses to translate unsafe query predicates. The remaining risks are explicit boundaries and projections that hide work.

var rows = await db.Orders
    .Where(o => o.CustomerId == customerId)
    .Select(o => new OrderRow(o.Id, FormatCurrency(o.Total)))
    .ToListAsync();

Complex types, part 2: choose the storage shape before the API

EF Core 11 broadens complex-type modelling, but the database shape still decides what you can index, query and migrate safely.

modelBuilder.Entity<Customer>(customer =>
{
    customer.ComplexProperty(c => c.BillingAddress, address =>
    {
        address.Property(a => a.Postcode).HasMaxLength(12);
    });

    customer.HasIndex(c => c.BillingAddress.Postcode);
});

JSON columns: queryable, but never provider-neutral

EF Core keeps improving JSON translation, especially for SQL Server, but JSON is where provider differences show up fastest.

var candidates = db.Products
    .Where(p => EF.Functions.JsonPathExists(
        p.SearchDocument,
        "$.tags[*] ? (@ == \"priority\")"));

Migrations in CI/CD: choose the artefact, not just the command

The migration workflow question is operational: who reviews the SQL, who runs it, and which binary produced it?

dotnet ef migrations bundle `
  --configuration Release `
  --self-contained false `
  --output .\artifacts\migrate.exe

dotnet ef migrations script `
  --idempotent `
  --no-build `
  --output .\artifacts\migrate.sql

dotnet ef database update `
  --no-build

Upgrade checklist: EF Core 10 model to EF Core 11

Treat EF Core 11 as a query-and-migration review, not a package bump.

1. Upgrade EF packages and the local dotnet-ef tool together. Keep runtime and design-time versions aligned.
2. Regenerate a migration and read it. Complex-member indexes, provider defaults and snapshot changes show up there first.
3. Capture SQL for hot queries. Focus on joins, extrema, grouping, JSON predicates and provider-specific functions.
4. Run the same tests on the real provider. SQLite is an excellent lab provider, not proof that SQL Server or PostgreSQL SQL is identical.
5. Retest client-visible ordering and paging. Query improvements can still change plans, null handling or result order when previous code relied on accidental behaviour.

Performance: what changed, and what did not

EF Core 11 query translation improvements help, but the old performance levers are still the first line of defence.

static readonly Func<OrdersContext, int, Task<Order?>> LatestOrder =
    EF.CompileAsyncQuery((OrdersContext db, int customerId) =>
        db.Orders
          .AsNoTracking()
          .Where(o => o.CustomerId == customerId)
          .OrderByDescending(o => o.CreatedAt)
          .FirstOrDefault());

Provider reality check: do not demo SQL your engine cannot run

EF Core is a common abstraction over providers that deliberately expose different database capabilities.

Explicit Property() on a collection stops working

Working EF Core 10 code that compiles unchanged on EF Core 11 and then throws at query time. It targets exactly the teams who write explicit entity configuration — which is most enterprises.

public class Team
{
    public int Id { get; set; }
    public List<int> Scores { get; set; } = new();
}

protected override void OnModelCreating(ModelBuilder mb)
{
    // The way an IEntityTypeConfiguration class writes it
    mb.Entity<Team>().Property(t => t.Scores);
}

var n = ctx.Teams.Count(t => t.Scores.Contains(2));

EF assembly: 10.0.12.0
RESULT: query succeeded, rows = 1

EF assembly: 11.0.0.0
RESULT: InvalidOperationException: The LINQ expression 'DbSet<Team>()
    .Count(t => t.Scores
        .Contains(2))' could not be translated.

mb.Entity<Team>().PrimitiveCollection(t => t.Scores);

EF assembly: 11.0.0.0
RESULT: query succeeded, rows = 1

Lab 09 — upgrade the data model 25 min

This is Day 1's Lab 04 again, upgraded to EF Core 11 and net11.0.

cd labs/Day2/09-EfCore11-Migration/start
dotnet build
dotnet tool restore

Your tasks:

1. Retarget the project to net11.0.
2. Upgrade the EF Core packages and the local dotnet-ef tool.
3. Put an index on a complex type property.
4. Use the new single-step migration creation-and-application workflow.
5. Try MinBy and MaxBy translation, then inspect the generated SQL.

.NET 12 outlook: signals, not features Outlook

There is no .NET 12 documentation, no preview and no released feature list today.

Direction of travel from .NET 10 and 11

These are not .NET 12 features. They are the areas where the current releases clearly show unfinished or continuing work.

The decision: stay on 10, take 11, or split

This is the real close of the workshop: choose the support model that matches your organisation, not the release with the longest feature list.

So the decision is not about support duration. Strip that out and what remains is the real question: is the upgrade work itself worth doing twice?

The .NET 12 boundary: what the release index says

A useful outlook starts by separating known facts from attractive guesses.

Plan for cadence, not clairvoyance

You can build a robust upgrade plan without knowing a single future feature. Anchor on support policy, evidence gates and rehearsals.

A cadence that survives not knowing

Separate production commitment from learning. The same organisation can be conservative in production and aggressive in evidence gathering.

What to brief on Monday

Close the workshop with decisions the team can actually take back, not a speculative future-feature list.

1. State the baseline. Which services stay on .NET 10 LTS, and why?
2. Name the pilot. Which low-risk service is allowed to test .NET 11 RC 1?
3. Define the evidence. Hardware smoke test, OpenAPI toolchain check, runtime-async artefact check, diagnostics pass and workload measurement.
4. Assign owners. SDK installation, CI images, shared libraries, generated clients and observability tooling each need a named owner.
5. Record the boundary. No .NET 12 feature, date or version promise appears in the plan until there is a public channel to verify.

What to do in the next 30 days

Turn the workshop into evidence while it is still fresh.

1. Verify hardware baselines against .NET 11's raised minimum requirements.
2. Check whether your OpenAPI client generators, gateways and contract tests accept OpenAPI 3.2.
3. Audit for the C# 14 field breaking change before turning on the new compiler.
4. If you are still on .NET 8 or .NET 9, run the .NET 10 upgrade path first.
5. Pick one low-risk service as a .NET 11 RC rehearsal, and one LTS service to leave deliberately on .NET 10.