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)

„Implementiere Feature X“ – und schon spuckt das Large Language Model (LLM) komplexen Code aus, ohne dass die Entwicklerin oder der Entwickler nach der Architektur gefragt hat. Man erhält funktionsfähigen Code, kann aber nicht nachvollziehen, warum diese Entscheidungen getroffen wurden. Das Resultat: Developer verbringen mehr Zeit damit, generierten Code zu verstehen, als das eigentliche Problem zu lösen.

Im Gespräch mit Ralf D. Müller liefert Oliver Jägle, Senior Engineer bei DB Systel, eine überraschende Erklärung: Das LLM ist nicht schuld – wir kommunizieren schlecht, was wir brauchen. Mit „Responsible Vibe MCP“ demonstriert er, wie ein intelligenter „Conversation State Manager“ als digitaler Projektleiter fungiert und LLMs durch strukturierte Entwicklungsworkflows führt.

Statt sofortiger Code-Dumps führt das Tool systematisch durch Requirements-Klärung: Wer sind die Nutzer? Welche Constraints? Welche Features sind kritisch? Das Ergebnis: durchdachte, begründete Architektur-Entscheidungen statt zufälliger Tech-Stack-Kombinationen.

Ein praktisches Gespräch über die Transformation von Code-generierenden Maschinen zu durchdachten Entwicklungspartnern – durch bessere Kommunikation statt LLM-Zähmung.

Livestream am Freitag, 12. September

Die Ausstrahlung findet am Freitag, 12. September 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

(mdo)

Über Jahre verkaufte Apple ein sogenanntes MagSafe-Battery-Pack. Dabei handelte es sich um einen vergleichsweise dicken Akku, den man über Apples Magnettechnik auf den iPhone-Rücken klemmen konnte, um das Handy induktiv aufzuladen. Mittlerweile vom Markt genommen, feiert das Strompaket nun eine Wiedergeburt. Die ist allerdings sehr speziell: Die neue MagSafe-Batterie gibt es nur für das dünnste iPhone aller Zeiten, das iPhone Air.

Akku zu lang für andere iPhones

Obwohl Apple sich bei dem Modul an seinen eigenen MagSafe-Standard hält, will der Konzern offenbar nicht, dass man den 115 Euro teuren Zusatzakku mit anderen iPhones nutzt. Ob dieser „Kopierschutz“ auch Software-seitig umgesetzt wurde und was passiert, wenn man es trotzdem versucht, ist bislang noch unklar. Es gibt aktuell nur die offizielle Kompatibilitätsangabe – und dort steht Schwarz auf Weiß, dass die neue MagSafe-Batterie nur mit dem iPhone Air arbeitet.

Einer der Gründe dürfte die Form des Akkus sein: Er ist länglich und vergleichsweise schmal. Daher liefe er bei den anderen iPhone-17-Modellen – und möglicherweise auch diversen anderen iPhones – in den Kamerahügel hinein, eine MagSafe-Verbindung wäre also nicht möglich. Gehen könnte es, wenn man eine iPhone-Hülle verwendet, die den Kamerabereich „abflacht“. Allerdings würde dieser dann trotzdem verdeckt – unschön im täglichen Einsatz. Was jedoch vermutlich geht, ist eine Verwendung des Stromspeichers via USB-C. Der Stecker ist offenbar PowerDelivery-typisch bidirektional ausgelegt, spekuliert das Apple-Blog 9to5Mac.

65 Prozent mehr Strom, dafür dicker

Bislang ist unklar, wie viel mAh die MagSafe-Batterie liefert. Apple gibt nur an, dass ein iPhone Air so „bis zu 65 Prozent“ länger laufen soll – und damit auch ein iPhone 17 Pro Max schlägt. Das Aufladen via MagSafe ist nicht besonders flott: Laut Apple sind maximal 12 Watt drin, obwohl das Air bis zu 20 Watt Ladeleistung via MagSafe beherrscht. Aufgetankt wird der Stromspeicher via USB-C mit einem Netzteil, das mindestens 20 Watt haben soll. Angaben zu Ladezeiten machte Apple hier nicht.

Alles in allem ist die neue MagSafe-Batterie ein interessantes Produkt, zeigt aber auch, dass Apples ultraflaches iPhone Air eben kein Dauerläufer sein dürfte. Wer den Akku andockt, gibt das indirekt zu – und versaut sich die ganze Dünnheit. Apple betont, auch intern an Routinen geschraubt zu haben, um den integrierten Stromspeicher bestmöglich für „all day battery life“ auszunutzen. Wer das iPhone Air viel verwendet, dürfte hier aber schnell an praktische Grenzen stoßen. 3149 mAh hat die interne Batterie nur.

(bsc)