.NET 11 Preview: Was Unternehmen wissen müssen

Microsoft arbeitet seit Anfang des Jahres in mehreren Preview-Schritten an .NET 11 – und wer die letzten Ausgaben verfolgt hat, merkt schnell: Das ist mehr als das übliche Aufräumen zwischen zwei LTS-Versionen. Mit einer grundlegend überarbeiteten Async-Runtime, echten Union Types in C# 15 und einer ganzen Reihe praktischer Verbesserungen in ASP.NET Core zeichnet sich ab, wohin die Plattform sich entwickelt. Gleichzeitig steht ein Datum im Kalender, das für viele Unternehmen relevanter ist als jedes neue Sprachfeature: der 10. November 2026.

In diesem Artikel ordnen wir ein, was die aktuellen .NET-11-Previews bringen, was davon schon heute Beachtung verdient – und worauf Unternehmen sich unabhängig von der neuen Version jetzt vorbereiten sollten.

Runtime Async: Asynchrone Programmierung wandert in die Laufzeitumgebung

Async und await gehören seit .NET 4.5 zum festen Werkzeugkasten von C#-Entwicklern und haben seither zahlreiche andere Sprachen inspiriert. Technisch basierte asynchroner Code bislang jedoch auf einem Trick des Compilers: Aus jeder async-Methode erzeugte der Compiler eine Zustandsmaschine, die den Fortschritt der Ausführung an jedem Suspend-Punkt verwaltet. Das funktioniert zuverlässig, erzeugt aber zusätzlichen Speicher-Overhead und macht Stacktraces schwerer lesbar, weil sich echte Methodenaufrufe mit generiertem Infrastruktur-Code vermischen.

Genau hier setzt eine der größten Neuerungen von .NET 11 an: Die Common Language Runtime (CLR) unterstützt asynchrone Methoden künftig nativ. Statt einer vom Compiler erzeugten Zustandsmaschine kümmert sich die Laufzeitumgebung selbst um das Unterbrechen und Fortsetzen asynchroner Methoden. Der praktische Nutzen liegt vor allem in saubereren Stacktraces – reale Methoden erscheinen direkt im Call-Stack statt hinter mehreren Ebenen generierter Hilfskonstrukte –, in einer besseren Debugging-Erfahrung und in geringerem Overhead, was sich in Benchmarks bereits in niedrigerem Speicherverbrauch pro asynchronem Aufruf zeigt.

Wichtig für die Praxis: Runtime Async ist derzeit noch ein Preview-Feature. Um es zu nutzen, müssen Projekte Preview-Features und ein spezielles Compiler-Flag aktivieren:

xml

<PropertyGroup>
  <EnablePreviewFeatures>true</EnablePreviewFeatures>
  <Features>$(Features);runtime-async=on</Features>
</PropertyGroup>

Solange Bibliotheken von Drittanbietern nicht selbst mit aktiviertem Runtime Async neu kompiliert wurden, bleibt der reale Performancegewinn in produktivem Code überschaubar. Für neue, in sich geschlossene Komponenten lohnt sich ein Blick aber schon jetzt.

Union Types in C# 15: Endlich ein sauberer Weg für „entweder-oder“

Ein zweites Highlight betrifft die Sprache selbst: C# 15 bringt echte, vom Compiler geprüfte Union Types. Wer bislang Ergebnisse modellieren musste, die entweder ein Erfolgsobjekt oder einen von mehreren Fehlerfällen liefern, kannte bislang meist nur unbefriedigende Lösungen – abstrakte Basisklassen mit tiefen Vererbungshierarchien, Hilfsbibliotheken wie OneOf, oder schlicht object mit manuellen Typprüfungen an jeder Stelle.

Eine Union beschreibt stattdessen eine geschlossene Menge nicht notwendigerweise verwandter Typen:

csharp

public record class Success(User User);
public record class NotFound(int Id);
public record class ValidationError(string Message);

public union UserResult(Success, NotFound, ValidationError);

Die Zuweisung erfolgt über implizite Konvertierung, ganz ohne Wrapper-Objekte. Der eigentliche Mehrwert zeigt sich beim Pattern Matching: Weil der Compiler alle möglichen Fälle kennt, prüft er automatisch auf Vollständigkeit. Ein default-Zweig ist nicht mehr nötig, und vergessene Fälle werden schon beim Kompilieren gemeldet – ein spürbarer Gewinn an Robustheit gegenüber klassischen switch-Konstrukten auf Basisklassen. Als angenehmer Nebeneffekt lassen sich Union Types direkt über System.Text.Json serialisieren, und ASP.NET Core kann sie unmittelbar als Request- oder Response-Body verwenden – ideal für APIs, die entweder ein Ergebnis oder ein strukturiertes Fehlerobjekt zurückgeben sollen.

Ein Praxishinweis vorab: Intern wird der Wert einer Union derzeit als object? gehalten. Bei value-type-lastigen Szenarien (also vielen struct-Fällen) kann das zu Boxing führen. Für klassische, auf Records basierende Domänenmodelle spielt das in der Regel keine Rolle – wer aber performancekritischen Code mit vielen Struct-Varianten migriert, sollte das im Blick behalten und vor einer breiten Umstellung profilen.

ASP.NET Core, EF Core und mehr: viele kleine, praxisrelevante Schritte

Neben den beiden großen Themen bringen die .NET-11-Previews eine Reihe kleinerer, aber im Alltag durchaus spürbarer Verbesserungen mit:

ASP.NET Core: OpenAPI 3.2 wird zum Standard, Minimal APIs unterstützen asynchrone Validierung (etwa eine Datenbankabfrage, ob eine E-Mail-Adresse schon vergeben ist, ohne den Thread zu blockieren), dazu kommen automatischer CSRF-Schutz für Cross-Origin-Requests und Verbesserungen bei SignalR, etwa Token-Refresh in langlebigen Verbindungen.
EF Core: Neue LINQ-Übersetzungen wie FullJoin für SQL FULL OUTER JOIN oder List<T>.Exists als EXISTS-Subquery, außerdem Unterstützung für Komplextyp-Properties in Keys und Indizes sowie Indizes auf JSON-Spalten bei SQL Server.
.NET MAUI: Fortschritte bei der plattformübergreifenden UI-Komponente CollectionView sowie beim schrittweisen Wechsel von Mono zu CoreCLR als Ausführungsmodell.
SDK und Tooling: Erweiterte Optionen für dotnet test inklusive xUnit v3 und NUnit, Multi-Arch-Container-Support über Podman sowie kleinere Native-AOT-Images.

Für Teams, die APIs, Datenbankzugriffe oder Testinfrastruktur pflegen, lohnt sich ein genauerer Blick in die jeweiligen Release Notes – gerade die asynchrone Validierung und die neuen EF-Core-Übersetzungen sparen in der Praxis oft handgeschriebenen Workaround-Code.

.NET 11 wird kein LTS – ein Punkt, den viele übersehen

Bei aller Begeisterung für neue Features lohnt ein Blick auf das Support-Modell, denn hier liegt einer der wichtigsten Unterschiede zu .NET 10: .NET 10 ist eine LTS-Version (Long Term Support) mit drei Jahren Unterstützung bis November 2028. .NET 11 wird dagegen als STS-Version (Standard Term Support) erscheinen – mit nur zwei Jahren Support, der ebenfalls im November 2028 endet. Wer im November 2026 direkt auf .NET 11 wechselt, hat also denselben Support-Endpunkt wie ein Team, das heute schon auf .NET 10 setzt – allerdings ohne dessen einjährigen Vorsprung an Produktionserfahrung.

Dazu kommt eine technische Randbedingung, die auf älterer On-Premises-Hardware zum Stolperstein werden kann: .NET 11 hebt die minimale x86/x64-Baseline von x86-64-v1 auf x86-64-v2 an (unter anderem SSE4.2 und POPCNT werden vorausgesetzt), ReadyToRun-Ziele wandern Richtung x86-64-v3 (AVX2, FMA), und auf Arm64 unter Windows wird LSE-Unterstützung verlangt. Auf nicht kompatibler Hardware startet die Anwendung schlicht nicht mehr. Die meisten modernen Server und Cloud-Instanzen erfüllen das problemlos, ältere Bestandsserver im eigenen Rechenzentrum sollte man vor einem Umstieg aber gezielt prüfen.

Der wichtigere Termin steht nicht im Preview-Changelog

So spannend die neuen Features sind: Für die meisten Unternehmen ist ein anderes Datum entscheidender als jede einzelne Preview. Am 10. November 2026 erreichen sowohl .NET 8 als auch .NET 9 gleichzeitig das Ende des offiziellen Supports. Ab diesem Zeitpunkt gibt es für beide Versionen keine Sicherheitsupdates mehr – unabhängig davon, ob ein Unternehmen .NET 11 überhaupt einsetzen will. Pikant dabei: Genau in diesem Monat wird auch .NET 11 voraussichtlich erst allgemein verfügbar.

Als Zielversion für produktive Systeme empfiehlt sich .NET 10 als aktuelle LTS-Version, die noch bis November 2028 unterstützt wird und bereits von den Performanceverbesserungen der letzten Release-Zyklen profitiert. Wer noch auf .NET 8 oder 9 unterwegs ist, sollte die Migration jetzt einplanen und nicht bis kurz vor den Stichtag warten – der Umstieg selbst ist in den allermeisten Fällen unkritisch, unter Zeitdruck macht ihn aber niemand gerne. Und wer auf .NET 11 wartet, um die Migration in einem Rutsch zu erledigen, verpasst den Stichtag mit hoher Wahrscheinlichkeit, da .NET 11 zum Erscheinen naturgemäß noch nicht produktionsreif sein wird.

Entscheidungshilfe: Welche Version ist die richtige?

Die Zielversion hängt vor allem vom aktuellen Ausgangspunkt ab:

Noch auf .NET 8 oder älter? Migration auf .NET 10 jetzt einplanen – nicht auf .NET 11 warten, das rechtzeitig vor dem Stichtag ohnehin nicht produktionsreif sein wird.
Bereits auf .NET 9? Der Umstieg auf .NET 10 ist meist der kleinste Migrationsschritt, den man sich vorstellen kann, und lohnt sich schon aus Support-Gründen.
Schon auf .NET 10? Kein Handlungsdruck bis 2028. .NET 11 lässt sich in Ruhe evaluieren, sobald es GA ist – vor allem für Workloads, die stark von Runtime Async profitieren.
Neues Projekt, Start Ende 2026 oder später? Auf .NET 10 starten und bei Bedarf nach GA auf .NET 11 wechseln, statt eine Preview als Zielplattform zu wählen.

Als Faustregel gilt: .NET 11 ist keine bessere Version von .NET 10, sondern eine fokussierte STS-Ergänzung – tief statt breit. Wer produktionskritische Systeme betreibt, sollte auf keinen Fall eine Preview-Version als Migrationsziel wählen.

Unsere Einschätzung

.NET 11 zeigt schon in der Preview-Phase, dass Microsoft an zwei Fronten gleichzeitig arbeitet: an spürbaren strukturellen Verbesserungen der Laufzeitumgebung mit Runtime Async und an einer Sprache, die mit Union Types einen jahrelang gewünschten Baustein für robusteres Fehler- und Ergebnishandling erhält. Für neue Projekte lohnt es sich, beide Themen im Auge zu behalten – produktiv einsetzen sollte man sie aber erst, wenn sie den Preview-Status verlassen haben, und nur dann, wenn das kürzere STS-Support-Fenster zum eigenen Upgrade-Rhythmus passt.

Kurzfristig wichtiger ist für die meisten Unternehmen jedoch die Migration weg von .NET 8 und 9 vor dem Support-Ende im November 2026 – am besten direkt auf die aktuelle LTS-Version .NET 10. Wenn Sie dabei Unterstützung benötigen – von der Bewertung des Migrationsaufwands bis zur konkreten Umsetzung – sprechen Sie uns gerne an.