EF Core 11: was sich abzeichnet
- Matt
Ich lese die Preview-Notizen zu .NET 11 seit dem Frühjahr mit, und EF Core liefert darin fast jedes Mal die Änderungen, die mich am meisten betreffen. Aktuell liegt Preview 6 vor, das Release ist für November 2026 angesetzt. Vier Punkte daraus haben sich bei mir festgesetzt.
Migration erzeugen und anwenden in einem Schritt
dotnet ef database update bekommt eine neue Option --add. Bisher musste man erst migrations add aufrufen, dann kompilieren, dann database update. Ab EF 11 reicht:
dotnet ef database update InitialCreate --add
Der Befehl scaffoldet die Migration, kompiliert sie über Roslyn zur Laufzeit und wendet sie sofort an - die Dateien landen trotzdem auf der Platte für die Versionskontrolle. Gedacht ist das für Fälle, in denen zur Laufzeit nicht neu kompiliert werden kann, etwa .NET Aspire oder Container-Images. Bei mir laufen die meisten Migrationen noch klassisch über die Kommandozeile im Projektverzeichnis, aber für ein containerisiertes Deployment ist das genau der Schritt, der bisher gefehlt hat.
Der Snapshot verrät divergierende Migrationen
Wer im Team an Migrationen arbeitet, kennt das Problem: Zwei Branches legen unabhängig voneinander Migrationen an, beide werden gemerged, und der Modellsnapshot passt zu keiner der beiden Historien mehr sauber. EF Core 11 schreibt jetzt die ID der zuletzt erzeugten Migration in den Snapshot. Ändern zwei Branches diese ID unabhängig voneinander, gibt es beim Merge einen Konflikt in genau dieser Zeile - ein sichtbarer Hinweis, dass die Migrationsbäume auseinandergelaufen sind, bevor es erst beim database update auf der anderen Maschine kracht.
Complex Types funktionieren jetzt auch mit TPT und TPC
Complex Types und JSON-Spalten ließen sich bisher nicht mit TPT- oder TPC-Vererbung kombinieren. EF 11 behebt das, dazu kommt eine ganze Reihe an Bugfixes rund um Vergleiche verschachtelter Complex Types und ExecuteUpdate darauf. Dazu passt eine kleinere Erleichterung: Die Konfiguration von Eigenschaften auf Complex Types lässt sich jetzt direkt verketten, Property(e => e.Details.Description) statt vorher über den Umweg ComplexProperty(e => e.Details).Property(d => d.Description). Klein, aber es macht die Fluent-API lesbarer.
Vektor-Spalten werden nicht mehr automatisch geladen
Wer SqlVector<T>-Spalten für Ähnlichkeitssuche nutzt, wie ich es in meinem Beitrag zu den Vector Data Extensions beschrieben habe, lädt die Spalte künftig nicht mehr automatisch mit, wenn eine Entität materialisiert wird - man muss sie explizit projizieren. Klingt nach Detail, macht laut den verlinkten Benchmarks aber fast das Neunfache an Durchsatz aus, gegen eine entfernte Azure-SQL-Datenbank sogar mehr als das Zwanzigfache, weil hunderte Float-Werte pro Zeile schlicht nicht mehr über die Leitung müssen.
Der Nachteil steckt im Kleingedruckten: Vektorsuche in SQL Server 2025 samt VECTOR_SEARCH() und den zugehörigen EF-APIs gilt weiterhin als experimentell, die Signaturen können sich bis zur finalen Version noch ändern. Und EF 11 selbst braucht die .NET-11-Runtime, ein Nebeneinander mit älteren Targets ist nicht vorgesehen. Bis November ist also noch Zeit, aber die Richtung steht schon fest.
Quelle: What’s New in EF Core 11