Letzte Woche, Mittelständler, Maschinenbau, 180 Mitarbeitende. Der Entwicklungsleiter öffnet seinen Laptop und zeigt mir ihren "aktuellen" Tech-Stack: .NET 6, EF Core 6, Razor Pages, alles grün im Deployment-Dashboard. "Läuft ja alles", sagt er. Dann kommt leise die Frage: "Müssen wir eigentlich was tun?"
Genau in diesem Moment erschien mein Browser-Tab mit der Meldung: .NET 11 Preview 5 ist da. Ich hab ihn nicht gezeigt. Nicht weil der Artikel schlecht wäre — er ist gut. Sondern weil die Antwort auf "Müssen wir was tun?" erst mal nicht ".NET 11" lautet.
Was Microsoft ankündigt
Das .NET-Team hat Preview 5 von .NET 11 veröffentlicht. Der Release bringt Verbesserungen quer durch den Stack: die Runtime wird schneller beim Async-Handling, der JIT-Compiler optimiert aggressiver, der GC bekommt besseres Trimming. In den Libraries kommt System.Text.Json mit JSON-Lines-Unterstützung, LINQ bekommt Full-Outer-Joins als First-Class-API. In C# kommen sogenannte Closed Class Hierarchies und Union Declarations — ein Feature, das Discriminated Unions aus F# endlich nach C# bringt. ASP.NET Core Blazor SSR unterstützt jetzt clientseitige Validierung ohne Server-Roundtrip, EF Core warnt aktiv, wenn async-Queries versehentlich synchron laufen (EF1004), und der SDK-Befehl dotnet new enthält jetzt ein Template für MCP-Server. Das Wichtigste vorab: .NET 11 ist kein LTS-Release. Support-Ende liegt voraussichtlich Mai 2028 — also neunzehn Monate nach dem geplanten GA im November 2026.
Wie das im Mittelstand wirklich landet
Ich arbeite regelmäßig mit Teams, die gerade von .NET Framework auf .NET 8 migriert haben — oder noch dabei sind. .NET 10 (LTS, seit November 2025) ist für die meisten dieser Teams noch frisch und ungetestet. .NET 11 ist konzeptionell interessant, aber operativ irrelevant für den überwiegenden Teil meiner Mandate. Hier ist mein ehrliches Scoring:
EF Core — EF1004 (async-Query läuft synchron): sofort relevant.
Das ist kein Preview-Feature, das kommt mit EF Core 11 — aber das Muster dahinter ist jetzt schon das häufigste Performance-Problem, das ich in .NET-Codebasen sehe. Teams schreiben .Result oder .GetAwaiter().GetResult() auf EF-Queries, weil "das doch immer so gemacht wurde". Das blockiert Thread-Pool-Threads, und bei 50 gleichzeitigen Requests bricht die App zusammen. Die Warnung, die Microsoft jetzt einbaut, hätte ich in drei von vier Mandaten im letzten Jahr gebraucht. Wenn du auf .NET 8 oder 10 bist: Aktiviere das via Roslyn-Analyzer schon heute, warte nicht auf .NET 11.
C# Union Declarations: relevant — für neue Projekte.
Discriminated Unions sind der richtige Weg, um Result-Typen sauber abzubilden. Keine Exception-basierten Flows mehr, kein null-Gefummel. Ich sehe das Muster mit OneOf-Libraries schon seit Jahren in produktivem Einsatz. Die native C#-Implementierung ist willkommen. Aber: Einführen in bestehenden Code kostet Refactoring-Budget. Für neue Microservices oder neue Bounded Contexts: ja. Für die 8 Jahre alte Auftragserfassungs-API: nein.
JSON Lines und Full-Outer-Joins in LINQ: nützlich, kein Dringlichkeitsfall. JSON Lines ist ein Serialisierungsformat für Streams — praktisch für Log-Ingestion, Event-Processing, Datei-basierte Pipelines. Full-Outer-Joins in LINQ schließen eine echte Lücke, die bisher manuelle GroupJoin-Verrenkungen erfordert hat. Beides lohnt sich auf dem Radar zu behalten, aber kein Upgrade-Grund.
MCP-Server-Template in dotnet new: aufpassen, das ist wichtiger als es klingt.
Microsoft baut ein Template für Model Context Protocol Server direkt in den SDK-Flow ein. Wer gerade überlegt, interne Werkzeuge für KI-Agenten zugänglich zu machen — etwa die interne Ersatzteildatenbank als Tool für einen Claude-Agenten — bekommt hier den niedrigschwelligsten Einstieg, den es je gab. Ich sehe das als Signal: Microsoft rechnet damit, dass .NET-Teams in den nächsten zwölf Monaten MCP-Infrastruktur bauen. Das Timing ist kein Zufall.
Blazor SSR mit clientseitiger Validierung: Hängt von deinem Blazor-Einsatz ab. Wer noch nicht auf Blazor ist, für den ist das kein Grund, es jetzt einzuführen. Wer Blazor Server produktiv betreibt und mit dem fehlenden Client-Validierungs-Feedback hadert: gutes Signal, dass die Plattform reifer wird. Kein Showstopper, aber ein Lebenszeichen in die richtige Richtung.
MAUI: Ich überspringe das hier bewusst. In meinen KMU-Mandaten wird MAUI selten ernsthaft eingesetzt. Die Teams, die mobile Apps bauen, bauen sie entweder nativ oder mit React Native / Flutter. MAUI-Stabilisierung ist gut, ändert aber an der Marktdynamik nichts.
Meine konkrete Empfehlung
Wenn du heute auf .NET 6 oder 7 bist: Das ist dein dringlichstes Problem, nicht .NET 11. .NET 6 läuft seit November 2024 out of support. .NET 7 seit Mai 2024. Migriere auf .NET 8 oder direkt auf .NET 10 (LTS). Beide haben drei Jahre aktiven Support.
Wenn du auf .NET 8 bist: Plane die Migration auf .NET 10 für Herbst 2026 ein — wenn .NET 11 GA geht, ist .NET 10 ein Jahr stabilisiert und der Migration-Path gut dokumentiert. Überspringe .NET 9 und .NET 11 als STS-Releases, wenn du keine dedizierten Test- und Upgrade-Ressourcen hast.
Wenn du auf .NET 10 bist: Preview 5 ist interessant zum Lesen. Fang an, die C#-Union-Features konzeptionell zu verstehen. Schaue dir das MCP-Template an, wenn du KI-Integration auf dem Roadmap hast. Aber migriere nicht auf .NET 11 im ersten Halbjahr nach GA — Preview-Zyklen bedeuten, dass Breaking Changes noch kommen können.
Die größte Gefahr beim Lesen von Preview-Ankündigungen ist nicht, dass man zu wenig aktualisiert. Die größte Gefahr ist, dass Teams anfangen, Features zu verfolgen statt Probleme zu lösen. EF1004 ist heute wichtiger als Union Declarations. Async-Performance ist heute wichtiger als JSON Lines.
Der vollständige Original-Beitrag von .NET Blog (MS): .NET 11 Preview 5 is now available!
Wo steht dein Team gerade in der .NET-Version? Wenn du dir nicht sicher bist, ob dein Upgrade-Pfad stimmt — oder ob ihr vielleicht gerade unwissentlich synchrone EF-Queries produziert — reden wir kurz.
— Bernhard