.NET 11 Preview 1: Große Fortschritte bei der Laufzeitumgebung, noch größere Fragen zur Ausrichtung
Microsoft veröffentlicht im Februar die erste Vorabversion von .NET 11 und bietet damit Laufzeitverbesserungen. Unser Team bei Iron Software hat .NET 11 Preview 1 geprüft, und es gibt einige Änderungen, die für die .NET Entwicklergemeinschaft hervorzuheben sind.
TL;DR
- Asynchrone Prozesse werden in die Laufzeitumgebung verlagert – schneller, besser optimiert und einfacher zu debuggen. Gute Nachrichten für unsere Universalprodukte.
- CoreCLR erhält WASM-Unterstützung – ersetzt Mono, sodass browserkompilierter .NET Code merklich schneller laufen sollte.
- Native Zstandard-Komprimierung - wir prüfen die Möglichkeit, sie in IronZIP intern zu implementieren.
Microsoft hat offiziell .NET 11 Preview 1 veröffentlicht, den ersten Meilenstein im Entwicklungszyklus für die nächste Version mit Standard Term Support, die im November 2026 erscheinen soll.
Asynchrone Laufzeitumgebung: Die stille große Veränderung
Eine der wichtigsten Neuerungen in Preview 1 ist, dass die asynchrone Nachverfolgung nun tiefer in die Laufzeitumgebung selbst integriert wird, anstatt vollständig vom Compiler übernommen zu werden.
Zur Einordnung: Asynchrone Programmierung ist das Muster, das es Anwendungen ermöglicht, Aufgaben in nicht blockierenden Abschnitten auszuführen, sodass der gesamte Thread nicht einfriert, während er auf einen Netzwerkaufruf, das Lesen einer Datei oder eine Datenbankantwort wartet. Es ist grundlegend für die moderne .NET -Entwicklung. Die meisten APIs, Dienste und UI-gesteuerten Workloads sind stark davon abhängig.
Indem Microsoft die asynchrone Koordination näher an die Laufzeitschicht verlagert, können beide Schwachstellen gleichzeitig behoben werden:
Debugging: Asynchrone Abläufe wurden rekonstruiert. Der Debugger sollte nun endlich in der Lage sein, Ausführungspfade über await-Anweisungen hinweg zu verfolgen und den Kontext wiederherzustellen, der aktuell verloren geht.
Leistung: Geringerer Koordinierungsaufwand. Die Laufzeitoptimierung kann aggressiver sein als die vom Compiler generierten Zustandsautomaten allein, wodurch die Kosten pro Aufgabe reduziert werden.
Für verteilte Dienste, Cloud-native APIs und UI-Anwendungen könnte dies zu messbaren Verbesserungen auf allen Ebenen führen.
CoreCLR kommt zu WebAssembly
Bislang basierten .NET Anwendungen, die für WebAssembly kompiliert wurden, auf Mono, der älteren Laufzeitumgebung, die ursprünglich für plattformübergreifende Kompatibilität entwickelt wurde. Mono funktioniert, hat aber bekannte Leistungsgrenzen und profitiert nicht von den gleichen Optimierungsinvestitionen wie CoreCLR.
Mit dieser Vorschau erhält CoreCLR Unterstützung für WebAssembly, was mehrere konkrete Verbesserungen mit sich bringt: JIT-Funktionen verbessern die Laufzeitausführungsgeschwindigkeit. Die Speicherverwaltung wird effizienter. Browserbasierte .NET Anwendungen nähern sich der Gleichstellung mit der nativen Ausführung an. Für Teams, die Blazor WebAssembly-Apps entwickeln oder mit browserseitigen .NET -Workloads experimentieren, ist dies eines der besten Upgrades in der gesamten Vorschau.
Dies ist auch für das gesamte Ökosystem von Bedeutung. Bibliotheken und Werkzeuge, die auf WASM abzielen, einschließlich browserbasierter Dokumentenverarbeitung, Rendering und Datenmanipulation.
Native Zstandard-Komprimierung
.NET 11 bietet erstklassige Unterstützung für den Zstandard (Zstd)-Komprimierungsalgorithmus durch eine neue ZstandardStream-Implementierung. Zstd hat sich in Hochleistungssystemen zu einem Standard entwickelt, da es bessere Kompressionsraten als Gzip, eine deutlich schnellere Dekomprimierung und einen hohen Durchsatz für die Verarbeitung großer Datenmengen bietet.
Für Bibliotheks- und Tool-Entwickler beseitigt dies die Reibungsverluste durch Drittanbieter-Bindungen. Produkte mit hohem Kompressionsbedarf können Zstd nun nativ nutzen. Es ist leicht vorstellbar, dass dies im Hintergrund für Tools wie IronZIP oder ähnliche Arbeitsabläufe nützlich sein wird, bei denen sowohl die Leistung als auch die Dateigröße entscheidend sind.
Das übergeordnete Thema: .NETs Kurswechsel hin zu agentenbasierter KI
Neben den Verbesserungen zur Laufzeit wird die strategische Ausrichtung von .NET 11 immer deutlicher. Microsoft setzt stark auf das, was es "agentische KI" nennt – Anwendungen, die für die Interaktion mit KI-Agenten, Copilot-Workflows und strukturierten Modellkontexten entwickelt wurden. Dies umfasst die Unterstützung des Model Context Protocol, KI-gestützte Entwicklungsmuster und Frameworks, die .NET Anwendungen als Werkzeuge positionieren, die Agenten aufrufen und orchestrieren können.
Die Richtung ist nicht überraschend. Die gesamte Branche bewegt sich in Richtung KI-gestützter Arbeitsabläufe, und Microsoft hat jedes Interesse daran, .NET zu einem erstklassigen Bestandteil dieses Ökosystems zu machen.
Was hier wirklich zählt
Wenn wir die Diskussionen um die Roadmap beiseitelassen und uns ausschließlich auf die praktischen Auswirkungen konzentrieren, sind die Laufzeitverbesserungen die eigentliche Neuigkeit:
- Asynchrones Debuggen könnte endlich auch für komplexe Codebasen praktikabel werden.
Die WebAssembly-Performance kann sich durch den Ersatz von Mono durch CoreCLR merklich verbessern. - Die Zstd-Komprimierung wird erstklassig unterstützt, wodurch Abhängigkeiten von Drittanbietern entfallen.
Das sind keine spektakulären Funktionen. Sie werden keinen Applaus bei den Hauptvorträgen der Konferenz auslösen. Es sind jedoch Verbesserungen, die die Reibungsverluste im täglichen Entwicklungsprozess unauffällig verringern, und diese sind langfristig meist viel wichtiger als die wichtigsten Neuerungen.
Die Vorschau 1 zeigt bereits zwei Seiten des .NET Ökosystems: starke, sinnvolle Fortschritte in der Laufzeitumgebung und gleichzeitig eine wachsende Diskussion über die Sprachrichtung und die Prioritäten der Plattform. Diese Spannung muss nicht unbedingt etwas Schlechtes sein. Das bedeutet in der Regel, dass sich die Plattform in eine Richtung weiterentwickelt, die den Menschen tatsächlich wichtig ist.