11.03.2026 16:40 Uhr

Asynchrone Programmierung mit async und await gibt es seit Jahren in .NET. Nun liefert Microsoft eine neue Laufzeitumgebung für die asynchrone Ausführung.

Die Schlüsselwörter async und await sind in vielen modernen Programmiersprachen verankert, zum Beispiel in Python seit 2015, in JavaScript seit 2017, in Rust seit 2019 und in Swift seit 2021. Auf die Frage „Wer hat es erfunden?“ muss man in diesem Fall sagen: Microsoft. Im Jahr 2012 erschienen diese beiden Schlüsselwörter zuerst in C# Version 5.0 und Visual Basic .NET Version 11.0. Sie vereinfachten die asynchrone Programmierung für Entwicklerinnen und Entwickler gegenüber vorher existierenden Konzepten und inspirierten danach viele andere Programmiersprachen.

Was für Entwicklerinnen und Entwickler einfach ist, ist unter der Haube aber bis heute komplex: In den .NET-Sprachen sind async und await bisher im Compiler als State Machines realisiert. In .NET 11.0 Preview 2 bringt Microsoft nun eine weiterentwickelte Version der .NET-Laufzeitumgebung Common Language Runtime (CLR), die nativ das Aussetzen und die Wiederaufnahme asynchroner Methoden unterstützt. Das erzeugt nicht nur weniger Overhead als die bisherigen State Machines, sondern ermöglicht schlankere Stack Traces und einfacheres Debugging.

Listing 1 zeigt vier asynchrone Methoden, die sich gegenseitig aufrufen.

Listing 1: Verkettung asynchroner Methoden

Bisher sah man als Ergebnis von Listing 1 die State Machine im Stack Trace:

Mit der neuen Laufzeitunterstützung für Asynchronität ist der Stack Trace deutlich kompakter:

Auf dieser Basis konnte Microsoft auch das Debugging-Erlebnis verbessern, siehe Pull Request „Runtime support for breakpoints and stepping“ auf GitHub.

Allerdings erfordert die neue Unterstützung für Asynchronität in der Laufzeitumgebung aktuell noch, dass diese Neuerung in der Projektdatei separat aktiviert wird, siehe Listing 2.

Listing 2: Aktivierung der Asynchronität in der Laufzeitumgebung per Projekteinstellungen

Das TAR-Archivformat beherrscht .NET seit der Version 7.0 mit den Klassen TarFile, TarEntry, TarReader und TarWriter im Namensraum System.Formats.Tar. Bei der Erstellung einer TAR-Datei mit TarFile.CreateFromDirectory() und TarFile.CreateFromDirectoryAsync() wurde als Archivformat immer das PAX-Format (POSIX.1-2001) verwendet. Entwicklerinnen und Entwickler haben seit .NET 11.0 Preview 2 die Möglichkeit, alle vier TAR-Formate zu wählen: TarEntryFormat.V7 (das ursprüngliche TAR-Format), TarEntryFormat.Ustar (Unix Standard TAR), TarEntryFormat.Gnu und TarEntryFormat.Pax.

Dies geschieht durch den zusätzlichen Parameter mit einem Enumerationswert aus TarEntryFormat:

Ein wesentlicher Unterschied zwischen den TAR-Formaten sind die maximalen Dateilängen: V7 erlaubt nur maximal 100 Zeichen für den Namen eines Eintrags. Bei USTAR sind es 256 Zeichen. Bei GNU und PAX ist die Länge von Dateinamen unbegrenzt. Bei USTAR ist die Dateigröße auf 8 GB beschränkt.

Die LINQ-Operatoren MinBy() und MaxBy() hat Microsoft bereits in .NET 6.0 eingeführt. Anders als die schon seit der ersten LINQ-Version in .NET Framework 3.5 verfügbaren Operatoren Min() und Max() liefern MinBy() und MaxBy() nicht nur den Minimal- bzw. Maximalwert selbst, sondern das ganze umgebende Objekt mit. Bisher waren MinBy() und MaxBy() nur in LINQ-to-Objects einsetzbar. Das ändert sich nun in .NET 11.0: Auch Entity Framework Core kann diese LINQ-Operatoren in SQL-Befehle umsetzen, siehe Listing 3.

Listing 3: MinBy() und MaxBy() in Entity Framework Core 11.0

Während der LINQ-Operator Min() die MIN()-Funktion in SQL nutzt

erstellt MinBy() eine sortierte Datensatzmenge und liefert den obersten Datensatz mit TOP(1) zurück:

Die in .NET 8.0 eingeführte Blazor-Variante Static Server-Side Rendering (SSR) ist den vorherigen Ansätzen für die Erstellung von Multi-Page-Apps im modernen .NET (ASP.NET Core Model-View-Controller (MVC) und ASP.NET Core Razor Pages) überlegen, hinsichtlich des Komponentenmodells, der Razor-Syntax und des partiellen Seitenaustauschs. Allerdings gab es bis dato auch einige Funktionen in MVC und Razor Pages, die Blazor SSR nicht beherrschte. Dazu gehören das Caching von Seitenteilen, erweiterbare Bedingungen für Routenparameter und die Datenübergabe zwischen HTTP-Anfragen mit dem TempData-Objekt (siehe GitHub-Issue). Letzteres ist nun in .NET 11.0 Preview 2 möglich. Die Datenspeicherung erfolgt wahlweise als Cookie (CookieTempDataProvider) oder im Session Storage (SessionStorageTempDataProvider) des Webbrowsers.

Anders als bei MVC und Razor Pages ist TempData aber keine Property der Basisklasse, sondern muss als Cascading Parameter explizit konsumiert werden, siehe Listing 5. Dabei ist zu beachten, dass TempData wie bei MVC und Razor Pages nur Zeichenketten abspeichern kann, das heißt, komplexe Objekte müssen Entwicklerinnen und Entwickler selbst serialisieren, siehe Listing 4.

Listing 4: TempData in Blazor-SSR-Seite befüllen

Listing 5: TempData in Blazor-SSR-Seite auslesen

Geplant für kommende Preview-Versionen ist, dass das Auslesen von Daten aus TempData über eine Annotation [SupplyParameterFromTempData], mit der man eine Property annotieren kann, vereinfacht wird, siehe Pull Request.

Laut den Release Notes von .NET 11.0 Preview 2 gibt es folgende weitere Neuerungen:

Laut den Release Notes von .NET 11.0 Preview 2 gibt es in dieser Vorschauversion keine Neuerungen für die Sprachsyntax von Visual Basic und C# sowie das GUI-Framework Windows Forms. Bei der Windows Presentation Foundation (WPF) gibt es nur einen Bugfix.

.NET 11.0 soll im November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten. Bis dahin können Entwicklerinnen und Entwickler mit fünf weiteren Preview-Versionen von April bis August sowie jeweils einer Release-Candidate-Version im September und Oktober rechnen. heise developer wird jeweils berichten.

(mai)