Microsoft hat .NET-Version 11.0 Preview 3 zusammen mit Visual Studio 2026 Insiders Version 11709.129 veröffentlicht. .NET 11.0 umfasst die Sprachversion 15.0 der Programmiersprache C#.

Discriminated Unions

Eine Discriminated Union (oft auch Tagged Union, Algebraic Data Type oder Sum Type genannt) ist ein Datentyp, der genau einen von mehreren möglichen Typen enthalten kann, wobei jederzeit klar ist, welcher Typ gerade enthalten ist. Viele moderne Sprachen, wie F#, Rust, Swift oder TypeScript beherrschen dieses Konzept, andere wie Kotlin erlauben die Nachbildung. In C# musste man sich bisher mit dem Basistyp System.Object, Vererbung, Interfaces, Pattern Matching oder Umsetzungen auf Basis generischer Typen wie der Bibliothek OneOf behelfen.

Einen Union Type in C# 15.0 erstellen Entwicklerinnen und Entwickler mit dem neuen C#-Schlüsselwort union unter Angabe eines Namens und von einem oder mehreren Typen, beispielsweise

public union UnionName(Typ1, Typ2, Typ3);

Dabei müssen die angegebenen Typen keinerlei Gemeinsamkeiten besitzen: Weder eine Basisklasse noch eine Schnittstelle müssen sie teilen. Das Schlüsselwort null darf man nicht als Typ angeben. Nullable Values Types (z.B. int?) und Nullable Reference Types (Person?) sind aber erlaubt.

Einer Variablen des Typs UnionName kann man dann sowohl Instanzen von Typ1 und Typ2 als auch Typ3 sowie gegebenenfalls null zuweisen. Jede andere Objekttypzuweisung wird aber verhindert.

Mit dem Operator is oder Pattern Matching lässt sich abfragen, welchen konkreten Typ die Union-Typvariable enthält. Während beim Pattern Matching automatisch ein Casting auf den Zieltyp erfolgt, muss man ohne Pattern Matching die Eigenschaft Value nutzen, um an den konkreten Typ zu kommen. Allerdings liefert Value den Typ System.Object, sodass wieder ein Casting erforderlich wird.

Als Beispiel soll ein typischer Einsatzfall für Discriminated Unions dienen: Eine Operation der Geschäftslogik kann neben einem konkreten Ergebnisobjekt mit Zeichenketten, Zahlen oder Exception-Objekten verschiedene Fehlerfälle signalisieren. Beim Einsatz von switch-Ausdrücken warnt der Compiler, wenn der Block nicht alle Fälle abfragt, mit der Warnung CS8509: „The switch expression does not handle all possible values of its input type (it is not exhaustive).“

Union Types haben das Potenzial, in einigen Teilen der .NET-Anwendungsframeworks für Vereinfachungen zu sorgen, beispielsweise bei WebAPI-Operationen mit Typed Results. Aktuell ist dies noch nicht möglich, aber es steht auf der Roadmap für ASP.NET WebAPIs und ASP.NET Core SignalR sowie Blazor zur Realisierung bis Jahresende 2026.

Folgender Code zeigt einen C# 15.0 Union Type für differenzierte Rückgabetypen einer Geschäftslogikmethode:

#nullable enable
 
namespace NET11_Console.CS15;
 
public class Person
{
 public int ID { get; set; }
 public string Name { get; set; }
 public string Website { get; set; }
 
 public override string ToString()
 {
  return $"Person: #{ID} Name: {Name} Website: {Website}";
 }
}
 
public union PersonOperationResult(Person?, string, int?, Exception);
 
class BL
{
 public PersonOperationResult GetPerson(int ID)
 {
  try
  {
   if (ID <= 0) return "Ungültige Person-ID";
   if (ID == 123) return new Person() { ID = ID, Name = "Dr. Holger Schwichtenberg", Website = "www.IT-Visions.de" };
   if (ID == 0815) throw new ApplicationException("Anwendungsfehler");
   return ID; // Person nicht gefunden
  }
  catch (Exception ex)
  {
   return ex;
  }
 
 }
}
 
class UnionTypeDemo
{
 public void Run()
 {
  CUI.Demo(nameof(UnionTypeDemo));
  BL BL = new();
 
  CUI.H1("\nLade Person mit ID 123");
  PersonOperationResult result1 = BL.GetPerson(123);
  PrintResult(result1);
 
  CUI.H1("\nTest mit Null-Wert");
  PersonOperationResult result2 = null;
  PrintResult(result2);
 
  CUI.H1("\nLade Person mit ID 0 (Fehlerfall)");
  PersonOperationResult result3 = BL.GetPerson(-1);
  PrintResult(result3);
 
  CUI.H1("\nLade Person mit ID 101 (nicht gefunden)");
  PersonOperationResult result4 = BL.GetPerson(101);
  PrintResult(result4);
 
  CUI.H1("\nLade Person mit ID 0815 (Anwendungsfehler)");
  PersonOperationResult result5 = BL.GetPerson(0815);
  PrintResult(result5);
 
  // Nicht erlaubt
  //PersonOperationResult result = new FileInfo(@"c:\temp\Datei.xy");
 }
 
 private static void PrintResult(PersonOperationResult result)
 {
  if (result is int)
  {
   CUI.Error($"Person #{result.Value} nicht gefunden");
  }
  else if (result is string)
  {
   CUI.Error($"Fehler: {result.Value}");
  }
  else if (result is Exception)
  {
   CUI.Error($"Fehler: {(result.Value as Exception).Message}");
  }
  else if (result is Person)
  {
   CUI.Print(result.Value);
  }
  else if (result is null)
  {
   CUI.Error("Null-Wert");
  }
 }
 
 private static void PrintResult_PatternMatching(PersonOperationResult result)
 {
  if (result is int i)
  {
   CUI.Error($"Person #{i} nicht gefunden");
  }
  else if (result is string s)
  {
   CUI.Error($"Fehler: {s}");
  }
  else if (result is Exception ex)
  {
   CUI.Error($"Fehler: {ex.Message}");
  }
  else if (result is Person p)
  {
   CUI.Print(p);
  }
 }
 
 private static void PrintResult_Switch(PersonOperationResult result)
 {
  Console.WriteLine(result switch
  {
   Person p => $"Person: {p.Name}",
   string s => $"Fehler: {s}",
   Exception ex => $"Fehler: {ex.Message}",
   int i => $"Person #{i} nicht gefunden",
   null => "Null-Wert"
  });
 }
}

Eine erste Unterstützung für Union Types gab es in Preview 2 von .NET 11.0 im März. Allerdings hatte Microsoft dieses Feature in dem Blogeintrag vergessen zu erwähnen. In den Release Notes zu .NET 11.0 Preview 2 führte der C#-Link ins Nirvana. Anfang April gab es dann einen Blogeintrag, der nachlieferte, dass Union Types in Preview 2 schon möglich waren, allerdings ohne Editor-Unterstützung. Der Editor funktioniert nun für Union Types in der Visual Studio-Version 2026 Insiders 11709.129.

Allerdings fehlt auch in Preview 3 immer noch ein Stück Code in der Basisklassenbibliothek. Neben dem Tag preview in der Projektdatei müssen Entwicklerinnen und Entwickler daher auch den Inhalt des folgenden Listings mit der Implementierung der Annotation [Union] via Klasse UnionAttribute in jedes Projekt aufnehmen, das Union Types nutzen will:

namespace System.Runtime.CompilerServices
{
 [AttributeUsage(AttributeTargets.Class | AttributeTargets.Struct,
     AllowMultiple = false)]
 public sealed class UnionAttribute : Attribute;
 
 public interface IUnion
 {
  object? Value { get; }
 }
}

Hintergrund ist, dass der C# 15.0-Compiler alle Union Types automatisch mit der Annotation [Union] versieht. Das erkennt man, wenn man den Union Type mit ILSpy dekompiliert:

// NET11_Console, Version=11.3.0.0, Culture=neutral, PublicKeyToken=null
// NET11_Console.CS15.PersonOperationResult
using System;
using System.Runtime.CompilerServices;
using NET11_Console.CS15;

[Union]
public struct PersonOperationResult : IUnion
{
    public object? Value { get; }

    [CompilerGenerated]
    public PersonOperationResult(Person? value)
    {
        Value = value;
    }

    [CompilerGenerated]
    public PersonOperationResult(string value)
    {
        Value = value;
    }

    [CompilerGenerated]
    public PersonOperationResult(int value)
    {
        Value = value;
    }

    [CompilerGenerated]
    public PersonOperationResult(Exception value)
    {
        Value = value;
    }
}

Neue und geänderte APIs

In .NET 11.0 Preview 1 hatte Microsoft die Komprimierung mit Zstandard als Alternative zu Deflate, GZip und Brotli eingeführt. In Preview 3 ist diese Implementierung nun Teil der System.IO.Compression.dll und nicht mehr der eigenständigen System.IO.Compression.Zstandard.dll. Zudem gibt es nun eine CRC32-Prüfung der Einträge, sodass fehlerhafte Archive schnell auffallen. In ASP.NET Core lässt sich Zstandard nun für die Komprimierung für HTTP verwenden. Das erfordert aber eine manuelle Aktivierung:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions
    {
        Quality = 6 // 1-22, higher = better compression, slower
    };
});

Im Objekt-relationalen Mapper Entity Framework Core gibt es eine neue Methode GetEntriesForState() in der Klasse ChangeTracker. Hiermit kann man sich alle Objekte liefern lassen, die sich in bestimmten Zuständen (Added, Modified, Deleted, Unchanged) befinden, beispielsweise

Im Gegensatz zu der vorher schon verfügbaren Operation Entries(), die diese Informationen ebenfalls bereitstellt, ruft GetEntriesForState() nicht vorher die Methode DetectChanges() auf, die in gut gefüllten Kontextinstanzen die Performance drücken kann.

In .NET MAUI gibt es nun einen LongPressGestureRecognizer, um auf längeres Drücken zu reagieren. Dabei kann man die Mindestdauer in Millisekunden angeben, ab wann die Geste als „lang“ gelten soll:

Auch das Landkartensteuerelement

Projektmappenfilter-Dateien mit .NET SDK CLI

Laut Release Notes soll man nun Projektmappenfilter-Dateien nicht nur über Visual Studio, sondern auch per Kommandozeile erstellen können. Microsoft liefert dazu in den Release Notes diesen Kommandozeilencode:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet sln MyApp.slnf list
dotnet sln MyApp.slnf remove src/Lib/Lib.csproj

Im Schnelltest zeigte sich aber, dass hier die Implementierung anders ist, als die Release Notes es anzeigen, denn

dotnet new slnf --name MyApp.slnf

legt eine Datei mit doppelter Dateinamenserweiterung an: MyApp.slnf.slnf. Man muss hier also die Dateinamenserweiterung weglassen, bei den Folgebefehlen muss sie aber stehen. Zudem funktioniert das Microsoft-Beispiel nur, wenn der Filter genau heißen soll wie die Projektmappendatei selbst, nur mit .slnf statt .slnx.

Folgender Code zeigt eine funktionierende Umsetzung mit abweichendem Namen:

$ErrorActionPreference = "stop"
$slnf = "NET11Blazor.slnf"
$slnfWithExtension = "$slnf.slnf"
dotnet new slnf --name $slnf -s www.IT-Visions.de_NET11_Demos.slnx --force
dotnet sln $slnfWithExtension add NET11_BlazorServer/NET11_BlazorServer.csproj
dotnet sln $slnfWithExtension add NET11_BlazorWASMStandalone/NET11_BlazorWASMStandalone.csproj
dotnet sln $slnfWithExtension list
dotnet sln $slnfWithExtension add NET11_BlazorWASMStandalone/NET11_BlazorWASMStandalone.csproj
dotnet sln $slnfWithExtension list 

Includes für File-based Apps

In .NET 10.0 hatte Microsoft sogenannte File-based Apps eingeführt, mit denen man C#-Programmcode in einer einzelnen Quellcodedatei direkt ohne Projektmappe und ohne vorheriges Kompilieren ausführen kann. In .NET 11.0 Preview 3 kommt die Erweiterung dieses Features um Include-Dateien. Damit kann man in einer C#-Datei andere Dateien über das neue Konstrukt #:include einbinden:

#:include ./Datenklasse.cs#:include ./Hilfsroutinen.cs 

Dafür benötigt man aktuell zusätzlich folgende Zeile:

#:property ExperimentalFileBasedProgramEnableIncludeDirective=true

Visual Studio Code Version 1.115 mit der aktuellen C# Dev Kit Version 3.11.200 meldet, dass der Editor das Feature noch nicht kennt:

Schemamigrationen mit Entity Framework Core

Beim Anlegen einer Datenbankschemamigration mit Add-Migration beziehungsweise dotnet ef migrations add speichert Entity Framework Core in der Snapshot-Datei, die den aktuellen Objektmodellzustand zum Zeitpunkt der Erstellung der Schemamigration repräsentiert, nun den Namen der aktuellen Schemamigration in einer Variablen mit dem Namen LatestMigrationId. Zudem gibt es dort einen Kommentar:

// If you encounter a merge conflict in the line below, it means you need to
// discard one of the migration branches and recreate its migrations on top of
// the other branch. See  for more info.
public override string LatestMigrationId => "20260415083524_v9";

Damit ist leichter erkennbar, dass es einen Versionsverwaltungskonflikt bei den Schemamigrationen gibt.

Verbesserungen für Async Runtime

Seit .NET 11.0 Preview 2 gibt es die asynchrone Laufzeitumgebung für .NET, die erstmals direkt async und await versteht, ohne dass der Compiler im Hintergrund eine State Machine dafür bauen muss. In Preview 3 hat Microsoft die asynchrone Laufzeitumgebung auch in Verbindung mit der direkten Erzeugung von Maschinencode mit ReadyToRun Images und Native AOT implementiert. Zudem ist die Projekteinstellung true nicht mehr notwendig. Um die asynchrone Laufzeitumgebung zu setzen, muss man nur noch runtime-async=on setzen.

Ausblick

Weitere Details finden sich in den Ankündigungen zu .NET-Version 11.0 Preview 3 und Visual Studio 2026 Insiders Version 11709.129.

.NET 11.0 soll im November 2026 erscheinen und einen Standard-Term-Support von zwei Jahren erhalten. Bis dahin ist mit vier weiteren Preview-Versionen von Mai bis August sowie jeweils einer Release-Candidate-Version im September und Oktober zu rechnen.

(rme)

Das Technologieberatungsunternehmen Thoughtworks hat die 34. Ausgabe seines halbjährlichen Technology Radar veröffentlicht. Zentrales Thema: sogenannte kognitive Schulden, die entstehen, wenn künstliche Intelligenz immer größere Codemengen generiert und das gemeinsame Verständnis von Softwaresystemen in Entwicklerteams schneller erodiert, als es sich erneuern lässt.

Während frühere Ausgaben des Radars die wachsenden Fähigkeiten von KI im Software-Engineering beleuchteten, verschiebt sich der Fokus dem aktuellen Report zufolge nun auf die Risiken beim Skalieren und im produktiven Einsatz. Der Unterschied zu klassischen technischen Schulden ist dabei wesentlich: Technische Schulden stecken im Code selbst, kognitive Schulden dagegen in den Köpfen der Entwicklerinnen und Entwickler. Die Kluft zwischen Mensch und System wird größer, wenn KI-generierter Code schneller entsteht, als Teams ihn durchdringen können.

Thoughtworks-CTO Rachel Laycock formuliert es so: „Der Wendepunkt, an dem wir uns befinden, hat weniger mit Technologie zu tun – es geht vielmehr um die Methode“. Die KI-Fähigkeiten haben sich im vergangenen Jahr in atemberaubendem Tempo entwickelt. Doch statt den Menschen zu verdrängen, zeige sich, dass geeignete Praktiken und technische Kontrollmechanismen nötig seien, um diese Fähigkeiten sicher und effektiv einzusetzen.

Kontrollmechanismen für Coding-Agenten

Ein zentrales Konzept des Radars sind sogenannte Harnesses – technische Kontrollmechanismen für KI-gestützte Coding-Agenten. Diese unterteilen sich in zwei Kategorien: Feedforward-Kontrollen steuern vor der Ausführung, etwa durch Agent Skills oder spezifikationsgetriebene Entwicklung. Feedback-Systeme hingegen beobachten die Ergebnisse nach der Ausführung – beispielsweise durch Mutationstests – und lösen eine Selbstkorrektur aus, bevor ein Mensch eingreifen muss. Ausführlich beschreibt dieses Konzept ein Artikel zu Harness Engineering von Birgitta Böckeler.

Zero Trust für KI-Agenten gefordert

Ein weiterer Schwerpunkt liegt auf der Absicherung von KI-Agenten, die zunehmend Zugriff auf private Daten und externe Systeme benötigen. Thoughtworks empfiehlt dafür Zero-Trust-Architekturen, Sandboxing und Defense-in-Depth-Strategien. Das Spannungsfeld zwischen maximalem Nutzen und Sicherheitsrisiken erfordere Prinzipien wie explizite Verifikation und minimale Rechtevergabe – Grundsätze, die auch mit Datenschutzanforderungen wie der DSGVO harmonieren.

Darüber hinaus empfiehlt der Radar eine Rückkehr zu bewährten Metriken wie den DORA-Kennzahlen (Deployment Frequency, Lead Time for Changes, Mean Time to Restore und Change Fail Percentage), um die steigende Komplexität messbar zu machen. Auch die Bewertung neuer Technologien werde durch einen Marktstau kleiner KI-Projekte und semantische Diffusion – also uneinheitliche Begriffsverwendung – zunehmend erschwert.

Passend dazu: Schneller coden, langsamer testen

Die Warnung vor kognitiven Schulden fügt sich in eine breitere Debatte ein. Wie auch andere Studien zeigen, beschleunigt generative KI zwar das Schreiben von Code, macht aber die Verifikation aufwendiger. Der Engpass verschiebt sich vom Erzeugen zum Verstehen und Prüfen. Genau an dieser Stelle setzt der Technology Radar an und fordert eine Rückbesinnung auf Engineering-Grundlagen, um die wachsenden Fähigkeiten von KI nachhaltig nutzen zu können.

Der interaktive Technology Radar steht online zur Verfügung, ein PDF-Download ist ebenfalls möglich.

(map)

Nginx 1.30.0 ist als neue Stable-Version erschienen und übernimmt zahlreiche Funktionen aus der 1.29.x-Mainline. Die wichtigsten Neuerungen betreffen moderne Webprotokolle und Transportmechanismen: HTTP Early Hints (103), HTTP/2-Verbindungen zu Backends, Encrypted ClientHello (ECH), Multipath TCP und Sticky Sessions. Außerdem ändert sich ein Standardverhalten: Das Proxy-Modul nutzt für Backend-Verbindungen nun HTTP/1.1 mit Keep-Alive.

Nginx ist ein weit verbreiteter Open-Source-Webserver, Reverse Proxy und Load Balancer, der vor allem in hochskalierenden Webanwendungen und Cloud-Umgebungen zum Einsatz kommt. Die Stable-Releases übernehmen erprobte Funktionen aus der Mainline und gelten als für den Produktiveinsatz geeignet.

Early Hints, HTTP/2 zu Backends und neues Proxy-Verhalten

Mit HTTP Early Hints kann Nginx Clients schon vor der eigentlichen Antwort auf benötigte Ressourcen hinweisen. Der Server schickt dazu einen HTTP-Statuscode 103 mit Preload-Headern, sodass Browser frühzeitig CSS- oder JavaScript-Dateien laden können – etwa während das Backend noch Inhalte rendert. Das verkürzt die wahrgenommene Ladezeit.

Neu ist auch die Möglichkeit, Backend-Server über HTTP/2 anzusprechen. Bisher nutzte Nginx für diese Verbindungen typischerweise HTTP/1.1. HTTP/2 erlaubt Multiplexing, also mehrere parallele Requests über eine einzige Verbindung. Davon profitieren vor allem Microservice-Architekturen, in denen ein API-Gateway viele Backend-Endpunkte gleichzeitig anspricht.

Eine kleine, aber praxisrelevante Änderung: Das Proxy-Modul verwendet nun standardmäßig HTTP/1.1 mit Keep-Alive für Backend-Verbindungen. Bestehende Verbindungen lassen sich so wiederverwenden, was die Zahl der Verbindungsaufbauten senkt und die Performance bei vielen kurzen Requests verbessert.

Verschlüsselung und Transport: ECH und Multipath TCP

Mit Encrypted ClientHello (ECH) verschlüsselt Nginx Teile des TLS-Handshakes – insbesondere die Server Name Indication (SNI). Dritte können damit beim Verbindungsaufbau nicht mehr erkennen, welche Domain ein Client anfragt. Die Integration setzt auf aktuelle OpenSSL-Schnittstellen und umfasst Anpassungen bei Logging und Fehlerbehandlung.

Ebenfalls neu: Unterstützung für Multipath TCP (MPTCP). Die Technik nutzt mehrere Netzwerkpfade gleichzeitig, etwa WLAN und Mobilfunk parallel. Verbindungen werden dadurch stabiler und können im Idealfall höhere Bandbreiten erreichen. Voraussetzung ist allerdings MPTCP-Support auf Betriebssystem- und Netzwerkebene.

Fürs Load Balancing bringt Nginx 1.30 Sticky Sessions mit. Sie leiten Anfragen eines Clients konsistent an denselben Backend-Server weiter. Das hilft bei zustandsbehafteten Anwendungen, die Session-Daten nicht zentral speichern. Das Keepalive-Modul für Upstreams ist nun standardmäßig aktiv. Zusammen mit dem geänderten Proxy-Verhalten (HTTP/1.1 mit Keep-Alive) reduziert das den Overhead bei der Verbindungsverwaltung zu Backends spürbar.

TLS-Stack und QUIC-Verbesserungen

Das Release enthält zahlreiche Verbesserungen rund um HTTP/3 und QUIC – darunter Stabilitätsfixes, Anpassungen an neue OpenSSL-3.5-APIs und Optimierungen beim Verbindungsmanagement. Hinzu kommt Unterstützung für TLS-Zertifikatskompression, die den Handshake schlanker macht. Das zahlt sich vor allem bei mobilen Clients und HTTP/3-Verbindungen aus.

Im TLS-Stack gibt es neue Callback-Mechanismen bei der ClientHello-Verarbeitung, die eine flexiblere Zertifikatsauswahl ermöglichen. Gleichzeitig hat das Projekt die Kompatibilität mit OpenSSL 4.0, BoringSSL und AWS-LC erweitert.

Konfiguration, Plattform und Bugfixes

Auf der Konfigurationsseite gibt es unter anderem eine neue max_headers-Direktive, die die Zahl der erlaubten Header begrenzt und so vor Missbrauch schützt. Auf macOS lassen sich jetzt TCP-Keepalive-Parameter konfigurieren.

Wie üblich umfasst das Release viele Bugfixes – unter anderem bei HTTP/2, HTTP/3, Proxying, gRPC und den Mail-Modulen. Die Entwickler haben dabei auch fehlerhafte Header-Verarbeitung, Integer-Überläufe und Validierungsfehler behoben.

Alle Informationen zu Nginx 1.30.0 finden sich in den Release Notes auf der GitHub-Projektseite.

Siehe auch:

(fo)