Nach Microsofts Plan sollte .NET 10.0 zum Ende der Preview-Phase vor dem frisch erschienenen Release Candidate 1 eigentlich „Feature Complete“ sein und die beiden Release-Candidate-Versionen sollten nur der Qualitätsverbesserung dienen. Das trifft laut Ankündigung auf Laufzeitumgebung, SDK, Sprachcompiler (C#, F#, Visual Basic .NET) und WPF auch zu. Wie schon in der Vergangenheit gibt es aber auch Teile von .NET, die noch signifikante neue Funktionen in Release Candidate 1 nachliefern. Dieses Mal betrifft es insbesondere Entity Framework Core und ASP.NET Core sowie MAUI.

Erste Version von Visual Studio 2026

.NET 10.0 Release Candidate 1 steht auf der .NET-Downloadseite bereit. Wie bei früheren Versionen besitzt der Release Candidate 1 eine Go-Live-Lizenz: Entwicklerinnen und Entwickler können die Version produktiv einsetzen und erhalten offiziellen Support von Microsoft. Gleichwohl müssen sie noch mit Änderungen rechnen bis zum Erscheinungstermin, der für den 11. November 2025 angekündigt ist.

Von Visual Studio 2022 gab es parallel ein Bugfixing-Update von Version 17.14.13 auf 17.14.14. Das Kompilieren einer .NET 10.0-Anwendung gelingt aber nur, wenn man 17.14.14 Preview 1.0 oder die erste Vorschauversion von Visual Studio 2026 (alias „18.0.0 Insiders“) verwendet. Die 2026er Version bietet neben noch mehr KI-Integration auch ein neues Look and Feel im Fluent Design mit zahlreichen neuen Themes wie Icy Mint, Cool Breeze, Mango Paradise und Spicy Red.

Zudem soll Visual Studio 2026 laut einem Blogbeitrag von Microsoft schneller sein. Bei der Installation fällt ein Detail positiv auf: Visual Studio 2026 fragt, ob man eine Konfiguration (Workloads, individuelle Komponenten, Erweiterungen und Einstellungen) aus einer auf dem Rechner vorhandenen Visual-Studio-2022-Installation oder einer .vsconfig-Datei übernehmen möchte (siehe die folgende Abbildung). Schon Visual Studio 2022 konnte bei der Installation .vsconfig-Dateien verwenden, aber nur beim Starten der IDE-Installation per Kommandozeile (Parameter --config).

Visual Studio 2026 bietet – im Gegensatz zu den beiden 2022er Versionen – auch die Installation des .NET-10.0-SDK als „Individual Component“ an. In den älteren Versionen muss man das .NET-SDK manuell von der Downloadseite installieren.

Entity Framework Core nutzt den Spaltentyp JSON

Entity Framework Core unterstützt ab Release Candidate 1 die beiden neuen Spaltentypen JSON und VECTOR, die es in Microsoft SQL Server 2025 (derzeit in der Preview-Phase und der Cloudvariante SQL Azure gibt. JSON hat Entity Framework Core auch bisher schon verwendet, um beispielsweise eine Liste primitiver Datentypen wie List auf eine einzige Tabellenspalte abzubilden – außer bei PostgreSQL, das nativ solche Mengen beherrscht – oder beim Speichern sogenannter Owned Types. Bisher kam dazu aber in der Datenbanktabelle der Spaltentyp nvarchar(max) in Verbindung mit der SQL-Funktion OPENJSON() zum Einsatz.

Nun verwendet Entity Framework Core hier den neuen nativen Spaltentyp JSON, sofern eine SQL-Server-Version angesprochen wird, die ihn beherrscht. Zudem muss man Entity Framework Core mitteilen, dass das Zielsystem JSON-Spalten kennt. Das geschieht durch Aufruf von UseSqlAzure() statt UseSqlServer() beim Zugriff auf eine Cloud-Datenbank. Beim lokalen Microsoft SQL Server muss man den Kompatibilitätslevel auf 170 setzen:

builder.UseSqlServer(connstring, x => x.UseCompatibilityLevel(170));

Neu in Entity Framework Core 10.0 Release Candidate 1 ist, dass Complex Types auch ein JSON-Mapping anbieten. Complex Types hat Microsoft in Entity Framework Core 8.0 als bessere Alternative zu Owned Types eingeführt und in Version 9.0 erweitert, aber in Complex Types wurde bisher kein JSON-Mapping angeboten, sondern sie wurden auf Spalten in der zum übergeordneten Objekttyp gehörenden Tabelle abgebildet. Daher waren sie bisher nur für 1:1-Beziehungen, nicht aber für 1:N-Beziehungen möglich. Das ändert sich in Entity Framework Core-Version 10.0: Hier ist der Aufruf ToJson() bei komplexen Typen im 1:1- und 1:N-Mapping möglich:

modelBuilder.Entity(x =>
{
  x.ComplexProperty(p => p.Address, p=>p.ToJson()); // 1:1-Mapping. NEU: p=>p.ToJson()                                                          
  x.ComplexProperty(p => p.ManagementSet, p => p.ToJson()); // NEU: 1:N mit p=>p.ToJson()
}

Laut den Release Notes kommt es dabei in Release Candidate 1 aber noch zu Problemen und man soll mit dem Praxiseinsatz auf Release Candidate 2 warten. Im Schnelltest zeigte sich, dass beim JSON-Mapping der komplexen Typen unter anderem das Gruppieren mit GroupBy() und die komplette Aktualisierung des komplexen Typen mit ExecuteUpdate() in Release Candidate 1 zu Laufzeitfehlern führen.

Einsatz von Vektoren

Als zweiten neuen SQL Server-Datentyp können Entwicklerinnen und Entwickler ab Release Candidate 1 Microsoft.Data.SqlTypes.SqlVector aus dem NuGet-Paket „Microsoft.Data.SqlClient“ (ab Version 6.1) beim objektrelationalen Mapping mit Entity Framework Core 10.0 verwenden. Ebenso gibt es eine neue EF-Core-Methode EF.Functions.VectorDistance() für die SQL-Funktion VECTOR_DISTANCE(). Bisher existierte für beides ein eigenständiges NuGet-Paket EFCore.SqlServer.VectorSearch. Allerdings kann man in Entity Framework Core 10.0 in LINQ-Abfragen noch nicht die SQL Server-Funktion VECTOR_SEARCH() nutzen.

Die Dokumentation enthält ein Codebeispiel für Vektordaten:

public class Blog
{
    // ...

    [Column(TypeName = "vector(1536)")]
    public SqlVector Embedding { get; set; }
}

…

IEmbeddingGenerator> embeddingGenerator = /* Set up your preferred embedding generator */;

var embedding = await embeddingGenerator.GenerateVectorAsync("Some text to be vectorized");
context.Blogs.Add(new Blog
{
    Name = "Some blog",
    Embedding = new SqlVector(embedding)
});
await context.SaveChangesAsync();

…

var sqlVector = new SqlVector(await embeddingGenerator.GenerateVectorAsync("Some user query to be vectorized"));
var topSimilarBlogs = context.Blogs
    .OrderBy(b => EF.Functions.VectorDistance("cosine", b.Embedding, sqlVector))
    .Take(3)
    .ToListAsync();

Mehr Optionen für Parametermengen

Bei einem Thema probiert Entity Framework Core seit Jahren verschiedene Strategien: die Übergabe von Parametermengen von .NET an das Datenbankmanagementsystem, beispielsweise um passende Datensätze zu einer Liste von Orten zu suchen:

List destinations = new List { "Berlin", "New York", "Paris" };
var flights = ctx.Flights
    .Where(f => destinations.Contains(f.Destination))
    .Take(5).ToList();

Entity Framework Core-Versionen 1.0 bis 7.0 haben die Werte aus der Menge [code]destinations[/code] einzeln als statische Werte übergeben:
SELECT TOP(@p) [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]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (N'Berlin', N'New York', N'Paris')

Das sorgte jedoch im Datenbankmanagementsystem für viele verschiedene Ausführungspläne.

Seit Version 8.0 übergibt Entity Framework Core die Liste als ein JSON-Array, das im SQL-Befehl mit OPENJSON() aufgeteilt wird:

SELECT TOP(@p) [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]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (
    SELECT [d].[value]
    FROM OPENJSON(@destinations) WITH ([value] nvarchar(30) '$') AS [d]
)

Das erschwerte dem Datenbankmanagementsystem die Optimierung der Ausführungspläne, da es die Zahl der Parameter nicht mehr kannte.

Seit Version 9.0 ist es möglich, über die Funktion EF.Constant() oder den globalen Aufruf TranslateParameterizedCollectionsToConstants() in der Kontextklasse in OnConfiguring() zum alten Verhalten zurückzukehren:

var flights1 = ctx.Flights
    .Where(f => EF.Constant(destinations).Contains(f.Destination))
    .Take(5).ToList();

Beim geänderten Standard konnten Entwicklerinnen und Entwickler im Einzelfall mit EF.Parameter() anschließend das JSON-Array übergeben.

Nun in Entity Framework Core 10.0 hat Microsoft abermals einen neuen Standard implementiert, nämlich die einzelne Übergabe der Werte als eigene Parameter:

SELECT TOP(@p) [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]
WHERE [f].[NonSmokingFlight] = CAST(1 AS bit) AND [f].[FlightDate] > GETDATE() AND [f].[FreeSeats] > CAST(0 AS smallint) AND [f].[Destination] IN (@destinations1, @destinations2, @destinations3)

Das geschieht im obigen Beispiel mit drei Werten. Entity Framework Core arbeitet aber auch noch bei 1000 Werten auf diese Weise, wie ein Schnelltest zeigte.

Man kann das alte Verhalten mit EF.Constant() und EF.Parameter() erzwingen, da die optimale Strategie auch davon abhängt, wie stark die Zahl der Werte zur Laufzeit variiert. Die globale Änderung des Standards erfolgt mit

UseParameterizedCollectionMode(ParameterTranslationMode.Constant). Erlaubt sind die Werte: Constant, Parameter und MultipleParameters. Die erst in Version 9.0 eingeführte Methode TranslateParameterizedCollectionsToConstants() existiert noch, aber sie ist als [Obsolete] markiert.

Verbesserungen bei ASP.NET Core

ASP.NET Core führt in Release Candidate 1 neue Metriken für ASP.NET Core Identity zum Überwachen der Benutzerverwaltung ein, beispielsweise aspnetcore.identity.user.create.duration, aspnetcore.identity.sign_in.sign_ins und aspnetcore.identity.sign_in.two_factor_clients_forgotten.

Der Persistent Component State in Blazor soll nun auch beim Einsatz der Enhanced Navigation beim statischen Server-Side-Rendering funktionieren

Um Instanzen von Klassen und Records in Blazor zu validieren, die Microsoft schon in der Preview-Phase von .NET 10.0 verbessert hatte, gibt es drei weitere Neuerungen:

• Validierungsannotationen können auch für Typen und nicht nur wie bisher für Properties definiert werden.
• Die neue Annotation [SkipValidation] schließt Typen und Properties von der Validierung aus.
• Ebenso werden alle mit [JsonIgnore] annotierten Properties nicht mehr validiert.

Zudem gibt es nochmals einige kleinere Verbesserungen für die OpenAPI-Schema-Generierung, wie in den Release Notes beschrieben ist.

Kleine Verbesserungen bei MAUI

Auch bei .NET MAUI gibt es neue Metriken für die Überwachung der Layout-Performance:

• layout.measure_count,
• layout.measure_duration,
• layout.arrange_count und
• layout.arrange_duration.

Das Steuerelement bietet neuerdings die Events WebViewInitializing() und WebViewInitialized(), um die Initialisierung anzupassen. Vergleichbare Ereignisse gab es zuvor im Steuerelement (BlazorWebViewInitializing() und BlazorWebViewInitialized()). Das Steuerelement besitzt nun die Eigenschaft IsRefreshEnabled zusätzlich zu IsEnabled.

Dark Mode bei Windows Forms

Das Windows-Forms-Teams schreibt in den Release Notes, dass der in .NET 9.0 eingeführte Dark Mode nicht mehr als experimentell gekennzeichnet ist. Gleichzeitig heißt es dort aber auch, dass die Arbeit am Dark Mode weitergehen wird.

Ausblick auf die stabile Version

Vor der für November angekündigten Veröffentlichung von .NET 10.0 ist noch ein weiterer Release Candidate im Oktober geplant. Als Erscheinungstermin für die stabile Version hat Microsoft den 11. November 2025 verkündet. iX, dpunkt.verlag und www.IT-Visions.de präsentieren .NET 10.0 am 18. November im eintägigen Online-Event betterCode() .NET.

(rme)