Entwicklung & Code
.NET 11.0 Preview 2 liefert asynchrone Runtime
Microsoft hat die zweite Preview-Version für .NET 11.0 veröffentlicht und bringt darin unter anderem Neuerungen für die asynchrone Programmierung.
Weiterlesen nach der Anzeige

Dr. Holger Schwichtenberg hat Fachbücher zu .NET 10.0, C# 14.0, Blazor 10.0 und Entity Framework Core 10.0 veröffentlicht. Er arbeitet als Berater und Trainer bei www.IT-Visions.de.
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.
using System.Diagnostics;
namespace NET11_Console.Runtime;
public class NET11_RuntimeAsync
{
public async Task Run()
{
await MethodeEbene1();
}
async Task MethodeEbene1()
{
await Task.CompletedTask;
await MethodeEbene2();
}
async Task MethodeEbene2()
{
await Task.CompletedTask;
await MethodeEbene3();
}
async Task MethodeEbene3()
{
await Task.CompletedTask;
Console.WriteLine(new StackTrace(fNeedFileInfo: true));
}
}
Listing 1: Verkettung asynchroner Methoden
Weiterlesen nach der Anzeige
Bisher sah man als Ergebnis von Listing 1 die State Machine im Stack Trace:
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3()
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2()
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1()
at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
at
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
stateMachine)
at NET11_Console.Runtime.NET11_RuntimeAsync.Run()
at Program.$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8
Mit der neuen Laufzeitunterstützung für Asynchronität ist der Stack Trace deutlich kompakter:
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
at Program.$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8
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.
net11.0
…
runtime-async=on
true
Listing 2: Aktivierung der Asynchronität in der Laufzeitumgebung per Projekteinstellungen
Alle TAR-Formate
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:
TarFile.CreateFromDirectory("d:\Export", @"t:\archiv.gnu.rar",
includeBaseDirectory: true, TarEntryFormat.Gnu);
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.
MinBy() und MaxBy() für Datenbankzugriffe
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.
var ctx = new DA.WWWings.WwwingsV1EnContext();
// Min vs. MinBy()
var wenigsteFreiePlaetze = ctx.Flights.Min(x => x.FreeSeats);
CUI.H1("Der Flug mit den wenigsten Plätzen hat " + wenigsteFreiePlaetze + " freie Plätze");
var flugMitDenWenigstenFreienPlaetzen = ctx.Flights.MinBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenWenigstenFreienPlaetzen);
// Max() vs. MaxBy()
var meisteFreiePlaetze = ctx.Flights.Max(x => x.FreeSeats);
CUI.H1("Der Flug mit den meisten freien Plätzen hat " + meisteFreiePlaetze + " freie Plätze");
var flugMitDenMeistenFreienPlaetzen = ctx.Flights.MaxBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenMeistenFreienPlaetzen);
Listing 3: MinBy() und MaxBy() in Entity Framework Core 11.0
Während der LINQ-Operator Min() die MIN()-Funktion in SQL nutzt
SELECT MIN([f].[FreeSeats])
FROM [Operation].[Flight] AS [f]
erstellt MinBy() eine sortierte Datensatzmenge und liefert den obersten Datensatz mit TOP(1) zurück:
SELECT TOP(1) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination],
[f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID],
[f].[Seats], [f].[Timestamp]
FROM [Operation].[Flight] AS [f]
ORDER BY [f].[FreeSeats]
Datenübergabe zwischen HTTP-Anfragen mit TempData
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.
@page "/Registration"
@using BlazorSSRSamples
@using Newtonsoft.Json
@inject NavigationManager NavigationManager
Ihr Name:
reg.Name)" />
Ihre E-Mail-Adresse:
reg.EMail)" />
@code {
[SupplyParameterFromForm]
RegistrationData reg { get; set; } = new();
[CascadingParameter]
public ITempData? TempData { get; set; }
private string? message;
private void HandleSubmit()
{
TempData!["Message"] = "Registrierung erfolgreich übermittelt!";
TempData!["Reg"] = System.Text.Json.JsonSerializer.Serialize(reg); // speichert nur Strings
TempData!["RegInfo"] = DateTime.Now.ToString();
NavigationManager.NavigateTo("RegistrationConfirm", new NavigationOptions() { ForceLoad = true });
}
}
Listing 4: TempData in Blazor-SSR-Seite befüllen
@page "/RegistrationConfirm"
@using BlazorSSRSamples
@inject NavigationManager NavigationManager
@message
@if (reg.HasValue)
{
Ihre Daten:
@reg.Name
@reg.EMail
}
@if (regInfo.HasValue)
{
Registriert am:
@regInfo
}
@code {
[CascadingParameter]
public ITempData? TempData { get; set; }
private string? message;
private string? regInfo;
BlazorSSRSamples.RegistrationData? reg { get; set; } = new();
protected override void OnInitialized()
{
message = TempData?.Get("Message") as string ?? "No message";
reg = System.Text.Json.JsonSerializer.Deserialize(TempData?.Get("Reg").ToString());
regInfo = TempData?.Get("regInfo") as string;
}
}
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.
Weitere Neuerungen in .NET 11.0 Preview 2
Laut den Release Notes von .NET 11.0 Preview 2 gibt es folgende weitere Neuerungen:
- Der in ASP.NET integrierte Webserver Kestrel lehnt nun ungültige Anfragen schneller ab, weil Microsoft intern auf das Auslösen einer
BadHttpRequestExceptionverzichtet und stattdessen eine Struktur zurückgibt. Das verbessert laut Microsoft den Durchsatz um 20 bis 40 Prozent bei Angriffen via Port Scanning oder mit fehlerhaften Anfragen. - .NET-Core-basierte WebAPIs unterstützen jetzt die Open API Specification in der Version 3.2. In .NET 10.0 war es Version 3.1.1.
- Für die Erstellung von Web-Worker-Projekten gibt es nun eine eigene Projektvorlage „.NET Web Worker“ in Visual Studio beziehungsweise an der Kommandozeile:
dotnet new webworker. Dabei entsteht eine DLL, die in Blazor-WebAssembly-basierten Anwendungen genutzt werden kann. - Bei Entity Framework Core kann man nun für SQL Server die dort eingebaute Volltextsuche via Fluent API konfigurieren:
modelBuilder.Entity(b =>
{
b.HasFullTextIndex(e => new { e.Titel, e.Text})
.HasKeyIndex("PK_FullTextEntity")
.HasLanguage("Titel", "German")
.HasLanguage("Text", "German");
});
- Ebenso steht in Entity Framework Core die Vektorsuche mit der SQL-Server-2025-Funktion
VECTOR_SEARCH()via LINQ-OperationVectorSearch()zur Verfügung:
var sqlVector = new SqlVector(EmbeddingsUtil.Get(suchBegriff));
var q = ctx.TexteSet.VectorSearch>(b => b.Embedding, sqlVector, "cosine", topN: 5);
Dabei ist zu beachten, dass man VECTOR_SEARCH() auch in der stabilen Version von SQL Server 2025 erst via SQL-Befehl aktivieren muss
ALTER DATABASE SCOPED CONFIGURATION SET PREVIEW_FEATURES ON
und in .NET die Warnung „EP9105“ deaktivieren muss:
#pragma warning disable EF9105 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.
- In .NET MAUI wurde das Steuerelement
verbessert. Die Syntax ist nun kompakter.
Außerdem kann man Elemente auf der Karte (Polygon, Polyline, Circle) nun per IsVisible und ZIndex steuern. Zudem gibt es Click()-Ereignisse auf diesen Elementen.
- Auch .NET-MAUI-Anwendungen für Apple-Betriebssysteme (iOS, tvOS und Mac Catalyst) können nun auf der .NET Core Runtime statt Mono laufen. Seit .NET 10.0 war dies experimentell für MAUI-Anwendungen auf Android möglich. Auch die Apple-Implementierung der .NET Core Runtime gilt aber als experimentell. Die Anwendungen werden aktuell durch die Umstellung aber größer und das Debugging ist noch eingeschränkt.
- Die Größe der Container Images von .NET SDK 11.0 Preview 2 ist gegenüber .NET 11.0 Preview 1 um 41 bis 44 MB (bis zu 17 Prozent) verkleinert, da Microsoft nun Hard Links für doppelte Dateien verwendet. Das gilt auch für die Installer für Linux und macOS.
Verkleinerte Docker-Images des .NET 11.0 Software Development Kit
(Bild: Microsoft)
Sonst nichts Neues
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.
Ausblick
.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)