.NET 11 Vorschau 3: Eine Entwicklerbewertung

C# 15 Unionstypen: das große Thema

Wenn Sie OneOf<T1, T2>-Bibliotheken schreiben, handgerollte versiegelte Aufzeichnungshierarchien erstellen oder F#-Entwickler beneiden, ist dies die Überschrift. C# 15 führt ein union-Schlüsselwort ein, das erklärt, dass ein Wert genau einer von einer festgelegten Menge an Typen ist, mit vom Compiler erzwungener Vollständigkeit. Unionstypen kamen in Preview 2 an; Preview 3 poliert die IDE-Unterstützung dafür.

Der Ansatz des C#-Teams nähert sich eher einer Typenvereinigung als F#-diskriminierte Vereinigungen: Die Mitgliedstypen sind bestehende Typen, die Sie separat definiert haben, keine Tags, die innerhalb der Union-Erklärung verschachtelt sind. Eine Union ist im Wesentlichen eine Struktur, die ein Objekt umhüllt und einschränkt, was hineingehen kann. Von der Aufrufstelle aus fühlt es sich nativ an - implizite Umwandlung von Mitgliedstypen in die union, exhaustive switch-Ausdrücke über Pet.Value, und kein Standardarm erforderlich, wenn der Compiler alle Fälle sieht.

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function

Die Vorteile sind real: Geschlossene Typen, keine ungültigen Zustände, Vollständigkeit zur Kompilierzeit statt NotImplementedExceptionat um 3 Uhr morgens. Fügen Sie der Union einen Hai hinzu und jeder Switch über Haustiere leuchtet mit Warnungen auf, bis Sie ihn behandeln.

Die Nachteile sind auch real und es lohnt sich, sie in jeder ehrlichen Bewertung zu kennzeichnen. Die freigelegte Objekt-Werteigenschaft ist ein Problem - es gibt eine offene GitHub-Diskussion darüber, sie hinter etwas typsicherem zu verbergen. Öffentliche Konstruktoren definieren implizit, welche Typen die Union akzeptiert, was weder entdeckbar noch explizit ist. F#-Interop ist ungelöst (die beiden Modelle sind grundlegend unterschiedlich). Und die umfassendere Geschichte der Vollständigkeit hat noch Lücken: Geschlossene Hierarchien und geschlossene Enums, die beiden Vorschläge, die das Bild vervollständigen würden, sind noch Vorschläge. Gewerkschaften allein sind großartig. Gewerkschaften plus geschlossene Enums plus geschlossene Hierarchien würden einen generationsübergreifenden Wandel darstellen. Wir sind noch nicht ganz dort.

Runtime Async V2 und JIT-Verbesserungen

Runtime Async ist die stille Neufassung von .NET, wie async/await tatsächlich ausgeführt wird. Anstatt dass der C#-Compiler eine Zustandsmaschinenklasse pro asynchroner Methode generiert, verwaltet das Laufzeitsystem selbst die Aussetzung und Wiederaufnahme. Der sichtbare Vorteil: sauberere Stack-Traces, kleinere Speicherzuweisungen und ein Debugger, der Sie nicht dazu zwingt, über MoveNext-Rahmen hinweg zu scrollen, um Ihren eigenen Code zu finden.

In Preview 3 entfällt die EnablePreviewFeatures-Anforderung bei Runtime Async. Sie müssen den Featureschalter <Features>runtime-async=on</Features> immer noch umlegen, aber Sie müssen nicht mehr jeden API-Aufruf in den Vorschau-Bereich aufnehmen. NativeAOT und ReadyToRun-Unterstützung sind ebenfalls in dieser Vorschau gelandet, was die Lücke zwischen JIT- und AOT-Szenarien schließt. Fortsetzungsobjekte werden aggressiver wiederverwendet, und lokale Variablen, die sich nicht geändert haben, werden nicht über die Aussetzung hinweg gespeichert. In asynchron-lastenintensiven Codepfaden - denken Sie an eine Kestrel-Pipeline oder einen EF Core-Abfragearbeiter - ist das ein bedeutender Rückgang des Zuweisungsdrucks.

Der JIT hat seine übliche Charge von "Ihr bestehender Code ist jetzt schneller, tun Sie nichts" erhalten:

• Multi-Ziel-Switch-Ausdrücke wie x is 0 oder 1 oder 2 oder 3 oder 4 werden jetzt in verschaltungslose Prüfungen gefaltet.
• Bounds-Checks bei Wert[^1] + Wert[^2]-Mustern werden aggressiver eliminiert, und der häufige Fall i + cns < len in Schleifen kollabiert sauber.
• Konvertierungen von unsigned-int zu float und unsigned-int zu double sind auf vor-AVX-512 x86-Hardware schneller - speziell, aber real, wenn Sie auf älteren Computern arbeiten.

WebAssembly-Nutzer erhalten das WebCIL-Payload-Loading direkt im Runtime, bessere Debug-Symbole und float[] / Span<float> / ArraySegment<float>-Marshaling ohne den Round-Trip-Overhead. Keines davon ist einzeln dramatisch, aber zusammen sind sie die Art von zusammenhängender Arbeit, die Blazor WASM weniger wie einen Kompromiss erscheinen lässt.

Der Haken dabei ist die Hardware-Grundlage. .NET 11 erhöht die Mindestanforderungen an den Befehlssatz für x86/x64 und Arm64. Apple Silicon und die meisten Linux-SBCs sind in Ordnung - das ReadyToRun-Ziel auf Arm64 fügt nur LSE hinzu -, aber sehr alte x86-Hardware ist nicht mehr geeignet. Überprüfen Sie Ihren Gerätestand, bevor Sie ein direktes Upgrade annehmen.

ASP.NET Core und Blazor

Zstandard ist hier das Highlight. ASP.NET Core unterstützt jetzt zstd sowohl für die Komprimierung von Antworten als auch für die Dekomprimierung von Anfragen und ist standardmäßig aktiviert, wenn Sie die Middleware hinzufügen. Die Konfiguration hat die Form, die Sie erwarten würden:

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

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

Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)

Für APIs, die JSON- oder Textinhalte an Clients liefern, die bereits zstd verwenden - zunehmend üblich in mobilen und gRPC-nahen Ökosystemen -, ist dies ein messbarer Gewinn in der Bandbreite, ohne auf eine Bibliothek eines Drittanbieters angewiesen zu sein. Es ist auch bemerkenswerterweise ein Community-Beitrag und kein Microsoft-interner, was ein gesundes Signal darstellt.

Blazors Virtualize<TItem> hört endlich auf anzunehmen, dass jede Zeile die gleiche Höhe hat. Das war eine lang anhaltende Irritation: Jede Liste mit variablem Inhalt - Kommentare, Chatnachrichten, irgendetwas mit umbrochenem Text - benötigte manuelle Workarounds. Jetzt misst die Komponente die Elemente zur Laufzeit. Die Preview 3-Veröffentlichung behebt auch eine Reihe von Blazor-Bugs: eine Nullreferenz in Virtualize, die Erkennung von Scroll-Containern mit overflow-x, die Web Worker-Vorlage in veröffentlichten WASM-Apps, TempData Lazy Loading Eckfälle und ein IJSObjectReference-Leak in ResourceCollectionProvider. Einzeln betrachtet klein, zusammengenommen die Art von Aufräumarbeiten, die signalisieren, dass das Framework über die "etwas Neues in jeder Version"-Phase hinausreift.

Kestrel beginnt auch, HTTP/3-Anfragen zu verarbeiten, ohne auf den Steuerungsstrom und das SETTINGS-Rahmen zu warten, was die Latenz der ersten Anforderung bei neuen Verbindungen verkürzt. Wenn Sie HTTP/3 P99s gemessen und seltsame Kaltstart-Enden gesehen haben, ist dies Ihre Lösung.

.NET MAUI

MAUI in Preview 3 dreht sich hauptsächlich um das Schließen von Lücken, die es zu lange wie eine Beta wirken ließen. Das Map-Steuerung erhält Pin-Clustering, benutzerdefinierte Pin-Symbole, benutzerdefiniertes JSON-Styling und Klick-Ereignisse auf Kreisen, Polygonen und Polylinien - all die Dinge, die echte Produktions-Map-UIs benötigen und die zuvor benutzerdefinierte Handler pro Plattform erforderten. Ein eingebauter LongPressGestureRecognizer ist jetzt verfügbar, ohne dass Sie Ihren eigenen erstellen müssen. Implizierte XAML-Namespace-Deklarationen sind standardmäßig aktiviert, was Vorlagen am Anfang jeder Datei reduziert.

Die Plattformparität wird gesteigert: Permissions.PostNotifications ist jetzt auf iOS implementiert (es war nur auf Android), und Android erhält Vorschauunterstützung für Android 17 und API-Stufe 37.

Die ehrliche Einschätzung: das ist stetige, sinnvolle Iteration, keine Neuerfindung. MAUI im Jahr 2026 ist an einem viel besseren Ort als MAUI im Jahr 2023, aber wenn Sie sich früher davon abgewandt haben, wird Preview 3 allein Sie nicht zurückziehen. Wenn Sie bereits bei MAUI sind, sind dies genau die QoL-Änderungen, die Sie wünschen.

SDK, CLI und .NET watch

Dies ist der Abschnitt, in dem die kleinen Dinge sich summieren. Ein paar, die meiner Meinung nach den täglichen Arbeitsablauf wirklich verändern:

.NET sln kann jetzt Lösungen Filter (.slnf) direkt von der CLI aus erstellen und bearbeiten. Für Monorepos und große Microsoft-ähnliche Lösungen war das Öffnen von 200-Projekt-SLNs, um an dreien zu arbeiten, ein echter Aufwand. Jetzt können Sie vom Terminal aus den Umfang festlegen:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

Dateibasierte Apps (das .NET run app.cs Arbeitsablauf) unterstützen endlich #:include, was bedeutet, dass C#-Skripte Hilfsprogrammfunktionen in separate Dateien aufteilen können. In Kombination mit Editor-Abschluss für die Direktive in Roslyn treibt dies dateibasierte Apps von "Spielerei" zu "geeignet für echte Automatisierungstools" - das Nischen-PowerShell und kleine Python-Skripte jahrelang in Besitz genommen haben.

.NET run -e FOO=BAR ermöglicht es Ihnen, Umgebungsvariablen über die Befehlszeile zu übergeben, ohne den Shellzustand zu exportieren oder Startprofile zu bearbeiten. Klein, aber wenn Sie jemals drei Terminals mit unterschiedlichen ASPNETCORE_ENVIRONMENT-Werten geöffnet hatten, kennen Sie den Schmerz.

.NET watch integriert sich mit Aspire Apphosts, startet nach einem Absturz beim nächsten Dateiwechsel automatisch neu und behandelt Ctrl+C eleganter für WinForms und WPF (ein ständiger Nervenkitzel). .NET format akzeptiert --framework für projekte mit mehreren Zielsetzungen. .NET test im MTP-Modus unterstützt --artifacts-path. Und .NET tool exec / dnx fordert nicht mehr um eine zusätzliche Genehmigung, was ein Reibungspunkt für einmalige Tool-Ausführungen war.

Die Schmerzpunkte

Eine ausgewogene Rezension schuldet den rauen Kanten, und Preview 3 hat sie.

Die Tooling-Story ist rau. Visual Studio 2026 ist immer noch in der Vorschau sechs Monate nachdem .NET 10 ausgeliefert wurde, und von Microsoft gehostete Build-Agenten haben noch keine stabile VS 2026-Unterstützung. Eine Änderung in einem .NET 10 SDK-Patch-Release erforderte MSBuild 18 (VS 2026), was eine klare Verletzung der SemVer-Garantien darstellt, die Microsoft bewirbt. Wer CI auf von Microsoft gehosteten Agenten ausführt, musste entweder SDK 10.0.4 festlegen oder auf Vorschau-Bildvarianten wechseln. Wenn Sie erwägen, CI-Pipelines auf .NET 11 Vorschauen zu verschieben, erwarten Sie mehr Vom gleichen - Vorschau-SDKs haben, nach eigener Aussage des Teams, Dinge in 10.0.2 und 10.0.3 gebrochen, bevor sie sich stabilisierten.

Runtime Async ist immer noch optional. Selbst ohne die Vorschau-Features-Schranke müssen Sie runtime-async=on umlegen. Das ist okay für Greenfield-Code; für über NuGet bereitgestellte Bibliotheken können Sie immer noch nicht davon ausgehen, dass Ihre Nutzer den Schalter aktiviert haben, sodass die praktischen Vorteile bis zur Standardaktivierung der Funktion aufgeschoben werden (nicht in .NET 11).

Anforderungen an die Hardware steigen. Die Mindestanforderungen an den Befehlssatz für x86/x64 wurden erhöht. Die meisten Teams werden es nicht bemerken. Einige werden - und sie werden es beim Einsatz feststellen, wenn sie nicht vorher prüfen.

STS, nicht LTS. .NET 11 wird für 24 Monate unterstützt. .NET 10, das derzeitige LTS, erhält 36 Monate. Für Unternehmen mit langsamen Upgraderythmen ist .NET 10 immer noch die konservativere Wahl, und das Einführen von .NET 11 bedeutet das Engagement für ein weiteres Upgrade im Jahr 2028. Das Argument für die Einführung eines STS ist die Funktionen; das Argument dagegen ist der Kalender.

Vorschau bedeutet Vorschau. Dies ist kein Stabilitätsanfall - der Vorschauprozess von Microsoft war gut -, aber Preview 3 ist kein Veröffentlichungskandidat. Produktionsbereitstellungen warten frühestens auf RC1. Interne Tools, Nebenprojekte und Explorationen sind momentan der richtige Umfang.

Urteil

Wenn Sie jeden Tag C# schreiben, lohnt es sich, .NET 11 Preview 3 diese Woche zu installieren und damit zu spielen - insbesondere, um sich mit Unionstypen auseinanderzusetzen, die die bedeutendste Sprachänderung seit Jahren darstellen. Wenn Sie Bibliotheken pflegen, bedeutet die Arbeit an JIT und Runtime Async, dass Ihr Code auf .NET 11 schneller wird, ohne dass Änderungen vorgenommen werden müssen, was die beste Art von Upgrade ist. Wenn Sie MAUI-Apps ausliefern, sind die Arbeiten an Landkarten und Gesten wirklicher Fortschritt.

Wenn Sie Produktions- .NET-Workloads ausführen, lautet die Antwort die langweilige: weiter planen, weiter beobachten und das GA im November vormerken. Die aufregenden Teile kommen an, aber die Tool-Kette - VS, Build-Agenten und die Patchkadenz des SDK - ist, wo die Reibung tatsächlich liegt, und sie wurde noch nicht gelöst.

| --- |

Quellen: .NET Blog-Ankündigung, Neues in .NET 11 (Microsoft Learn), Laufzeitveröffentlichungsnotizen, ASP.NET Core-Versionshinweise, SDK-Veröffentlichungsnotizen, Unionstypen in C# 15 erkunden.