Grundlegende Änderungen in EF Core 11 (EF11)

Diese Seite dokumentiert API- und Verhaltensänderungen, die das Potenzial haben, vorhandene Anwendungen, die von EF Core 10 auf EF Core 11 aktualisiert werden, zu unterbrechen. Überprüfen Sie frühere grundlegende Änderungen, wenn sie von einer früheren Version von EF Core aktualisiert werden:

• Grundlegende Änderungen in EF Core 10
• Grundlegende Änderungen in EF Core 9
• Grundlegende Änderungen in EF Core 8

Zusammenfassung

Änderungen mit mittlerer Auswirkung

Die Sync-I/O-Funktionalität über den Azure Cosmos DB-Anbieter wurde vollständig entfernt.

Nachverfolgung von Issue 37059

Altes Verhalten

Synchrone E/A über den Azure Cosmos DB-Anbieter wird seit EF 9.0 (note) nicht unterstützt. Das Aufrufen einer Synchronisierungs-E/A-API wie ToList oder SaveChanges hat eine Ausnahme ausgelöst, es sei denn, eine spezielle Opt-In wurde konfiguriert. Wenn die Opt-In konfiguriert wurde, funktionierten Synchronisierungs-E/A-APIs wie zuvor, wodurch der Anbieter eine "sync-over-async"-Blockierung für das Azure Cosmos DB SDK durchführt, was zu Deadlocks und anderen Leistungsproblemen führen kann.

Neues Verhalten

Ab EF Core 11.0 löst EF nun immer eine Ausnahme aus, wenn eine API mit synchronen E/A-Vorgängen aufgerufen wird. Es gibt keine Möglichkeit, die Verwendung von synchronen E/A-APIs wieder zu aktivieren.

Warum

Das synchrone Blockieren asynchroner Methoden ("sync-over-async") wird dringend abgeraten und kann zu Deadlock- und anderen Leistungsproblemen führen. Da das Azure Cosmos DB SDK nur asynchrone Methoden unterstützt, unterstützt auch der EF Cosmos-Anbieter asynchrone Methoden.

Gegenmaßnahmen

Konvertieren Sie Ihren Code, um asynchrone E/A-APIs anstelle von Synchronisierungs-E/A-APIs zu verwenden. Ersetzen Sie z. B. Aufrufe von SaveChanges() durch await SaveChangesAsync().

Microsoft. Data.SqlClient wurde auf 7.0 aktualisiert.

Altes Verhalten

EF Core 10 verwendete Microsoft.Data.SqlClient 6.x, das Azure/Entra ID-Authentifizierungsabhängigkeiten (z. B. Azure.Core, Azure.Identity und Microsoft.Identity.Client) im Kernpaket enthielt.

Neues Verhalten

EF Core 11 hängt jetzt von Microsoft ab. Data.SqlClient 7.0. Diese Version entfernt Azure/Entra ID (ehemals Azure Active Directory) Authentifizierungsabhängigkeiten aus dem Kernpaket. Wenn Ihre Anwendung Entra ID Authentifizierung verwendet (z. B. ActiveDirectoryDefault, ActiveDirectoryInteractive, ActiveDirectoryManagedIdentity oder ActiveDirectoryServicePrincipal), müssen Sie das paket Microsoft.Data.SqlClient.Extensions.Azure jetzt separat installieren.

Darüber hinaus wurde SqlAuthenticationMethod.ActiveDirectoryPassword als veraltet markiert.

Weitere Informationen finden Sie im Microsoft. Data.SqlClient 7.0 Versionshinweise.

Warum

Diese Änderung wurde in Microsoft vorgenommen. Data.SqlClient um Abhängigkeitsblähigkeiten für Anwendungen zu reduzieren, die keine Azure Authentifizierung verwenden, was insbesondere für containerisierte Bereitstellungen und lokale Entwicklung von Vorteil ist.

Gegenmaßnahmen

Wenn Ihre Anwendung Entra ID Authentifizierung mit SQL Server verwendet, fügen Sie einen Verweis auf das paket Microsoft.Data.SqlClient.Extensions.Azure in Ihrem Projekt hinzu:

<PackageReference Include="Microsoft.Data.SqlClient.Extensions.Azure" Version="7.0.0" />

Es sind keine Codeänderungen erforderlich, die über das Hinzufügen dieses Paketverweises hinausgehen. Wenn Sie SqlAuthenticationMethod.ActiveDirectoryPassword verwenden, migrieren Sie zu einer modernen Authentifizierungsmethode, wie ActiveDirectoryDefault oder ActiveDirectoryInteractive.

Änderungen mit geringer Auswirkung

EF Core wird jetzt standardmäßig ausgelöst, wenn keine Migrationen gefunden werden

Tracking Issue Nr. 35218

Altes Verhalten

Zuvor, wenn eine Datenbank ohne Migrationen in der Assembly mit Migrate oder MigrateAsync aufgerufen wurde, protokollierte EF Core eine Informationsnachricht und kehrte zurück, ohne Änderungen anzuwenden.

Neues Verhalten

Ab EF Core 11.0 löst EF Core standardmäßig eine Ausnahme aus, wenn keine Migrationen in der Assembly gefunden werden. Dies entspricht dem verhalten, das PendingModelChangesWarningin EF 9.0 eingeführt wurde.

Warum

Wenn keine Migrationen vorhanden sind und Migrate() oder MigrateAsync() aufgerufen werden, weist dies typischerweise auf eine Fehlkonfiguration hin. Anstatt leise fortzufahren und die Datenbank in einem potenziell falschen Zustand zu belassen, weist EF Core Entwickler jetzt sofort auf dieses Problem hin.

Gegenmaßnahmen

Wenn Sie absichtlich aufrufen Migrate() , ohne Migrationen zu haben (z. B. weil Sie das Datenbankschema auf andere Weise verwalten), entfernen Sie den Migrate() Aufruf, oder unterdrücken Sie die Ausnahme, indem Sie Warnungen konfigurieren:

options.ConfigureWarnings(w => w.Ignore(RelationalEventId.MigrationsNotFound))

Oder um das Ereignis zu protokollieren, anstatt eine Ausnahme auszulösen:

options.ConfigureWarnings(w => w.Log(RelationalEventId.MigrationsNotFound))

Die Eigenschaft EFOptimizeContext wurde entfernt.

Nachverfolgungsproblem Nr. 35079

Altes Verhalten

Zuvor konnte die EFOptimizeContext MSBuild-Eigenschaft auf true festgelegt werden, um während des Build‑ oder Veröffentlichungsvorgangs die Generierung des kompilierten Modells und vorkompilierter Abfragecodes zu aktivieren.

<EFOptimizeContext Condition="'$(Configuration)'=='Release'">true</EFOptimizeContext>

Neues Verhalten

Ab EF Core 11.0 wurde die EFOptimizeContext MSBuild-Eigenschaft entfernt. Die Codegenerierung wird jetzt ausschließlich über die EFScaffoldModelStage- und EFPrecompileQueriesStage-Eigenschaften gesteuert. Wenn PublishAOT auf true festgelegt ist, wird die Codegenerierung während der Veröffentlichung automatisch aktiviert, ohne zusätzliche Eigenschaften zu benötigen.

Warum

Die Eigenschaften EFScaffoldModelStage und EFPrecompileQueriesStage bieten bereits eine differenzierte Kontrolle darüber, wann die Codegenerierung auftritt. EFOptimizeContext war ein überflüssiges Aktivierungsgate.

Gegenmaßnahmen

Ersetzen Sie die Verwendung von EFOptimizeContext durch die Eigenschaften EFScaffoldModelStage und EFPrecompileQueriesStage. Diese können auf publish oder build festgelegt werden, um zu steuern, in welchem Stadium die Codegenerierung erfolgt:

<EFScaffoldModelStage>publish</EFScaffoldModelStage>
<EFPrecompileQueriesStage>publish</EFPrecompileQueriesStage>

Jeder andere Wert (z. B none. ) deaktiviert die entsprechende Generation.

Wenn Sie PublishAOT auf true gesetzt haben, wird die Codegenerierung beim Veröffentlichen automatisch aktiviert, und es ist keine zusätzliche Konfiguration erforderlich.

EF-Toolspakete verweisen nicht mehr auf Microsoft.EntityFrameworkCore.Design

Tracking-Issue Nr. 37739

Altes Verhalten

Zuvor hatten die Microsoft.EntityFrameworkCore.Tools und Microsoft.EntityFrameworkCore.Tasks NuGet-Pakete eine Abhängigkeit von Microsoft.EntityFrameworkCore.Design.

Neues Verhalten

Ab EF Core 11.0 haben die Microsoft.EntityFrameworkCore.Tools und Microsoft.EntityFrameworkCore.Tasks NuGet-Pakete keine Abhängigkeit mehr von Microsoft.EntityFrameworkCore.Design.

Warum

Es gab keine feste Abhängigkeit vom Code in Microsoft.EntityFrameworkCore.Design, und diese Abhängigkeit führte zu Problemen, wenn die neueste Version von Microsoft.EntityFrameworkCore.Tools in Projekten verwendet wurde, die auf ältere Frameworks abzielten.

Gegenmaßnahmen

Wenn Ihr Projekt davon abhängt, dass Microsoft.EntityFrameworkCore.Design transitiv über die Toolspakete bereitgestellt wird, fügen Sie in Ihrem Projekt einen direkten Verweis darauf hinzu.

<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="11.0.0" PrivateAssets="all" />

SqlVector-Eigenschaften werden standardmäßig nicht mehr geladen.

Verfolgungsproblem Nr. 37279

Altes Verhalten

Bisher hat EF Core beim Abfragen von Entitäten mit SqlVector<T>-Eigenschaften die Vektorspalte in SELECT-Anweisungen aufgenommen und die Eigenschaft in der zurückgegebenen Entität befüllt.

Neues Verhalten

Beim Materialisieren von Entitäten ab EF Core 11.0 sind SqlVector<T>-Eigenschaften nicht mehr in SELECT-Anweisungen enthalten. Die Eigenschaft ist bei zurückgegebenen Entitäten null.

Vektoreigenschaften können weiterhin in WHERE und ORDER BY Klauseln verwendet werden , einschließlich mit VectorDistance() und VectorSearch(); sie werden nur nicht in die Entitätsprojektion eingeschlossen.

Warum

Vektorspalten können sehr groß sein, die Hunderte oder Tausende von Gleitkommawerten enthalten. In den meisten Fällen werden Vektoren in die Datenbank geschrieben und dann für die Suche verwendet, ohne dass sie gelesen werden müssen. Indem Sie sie standardmäßig von SELECT ausschließen, werden unnötige Datenübertragungen vermieden.

Gegenmaßnahmen

Wenn Sie Vektor-Werte zurücklesen möchten, verwenden Sie eine explizite Projektion.

var embeddings = await context.Blogs
    .Select(b => new { b.Id, b.Embedding })
    .ToListAsync();

Cosmos: Leere Sammlungen geben jetzt eine leere Sammlung anstelle von NULL zurück.

Nachverfolgung von Issue 36577

Altes Verhalten

Bisher war die Collection‑Eigenschaft auf der materialisierten Entität null, wenn beim Abfragen über den Azure Cosmos DB-Anbieter eine eigenständige Sammlung keine Elemente enthielt.

Neues Verhalten

Ab EF Core 11.0 initialisiert der Azure Cosmos DB-Anbieter ordnungsgemäß leere eigenständige Sammlungen, wobei anstelle von null eine leere Sammlung zurückgegeben wird.

Warum

Das vorherige Verhalten, leere eigene Sammlungen als null zu materialisieren, war ein Fehler.

Gegenmaßnahmen

Wenn Ihr Code die Eigenschaften der eigenen Sammlung null explizit überprüft, um zu erkennen, dass die Auflistung leer ist, können diese Prüfungen einfach entfernt werden, da die Auflistung jetzt immer initialisiert wird:

// Before
if (entity.OwnedCollection is null or { Count: 0 })
{
    // treated as empty
}

// After
if (entity.OwnedCollection is { Count: 0 })
{
    // treated as empty
}

Microsoft.Data.Sqlite – Wichtige Änderungen

Zusammenfassung

Änderungen mit mittlerer Auswirkung

Verschlüsselungsfähige SQLite-Pakete wurden entfernt.

Nachverfolgung von Issue 5108

Altes Verhalten

Zuvor stellte das SQLitePCLRaw.bundle_e_sqlcipher NuGet-Paket verschlüsselungsfähige SQLite-Builds kostenlos bereit.

Neues Verhalten

Beginnend mit SQLitePCLRaw 3.0 (verwendet von Microsoft. Data.Sqlite 11.0), das SQLitePCLRaw.bundle_e_sqlcipher-Paket wurde veraltet und aus NuGet entfernt. Kostenlose SQLite-Builds mit Verschlüsselung werden nicht mehr verteilt.

Warum

Das bisherige No-Cost-Paket SQLitePCLRaw.bundle_e_sqlcipher wurde kaum beibehalten, was eine erhebliche Sorge für Verschlüsselungssoftware darstellt, bei der Sicherheitsrisiken möglicherweise nicht gepatcht werden. Der SQLitePCLRaw-Betreuer hat diese Builds in Version 3.0 zugunsten professionell verwalteter, kostenpflichtiger Alternativen entfernt, die fortlaufende Sicherheitsupdates bereitstellen.

Gegenmaßnahmen

Wenn Sie SQLite-Verschlüsselung benötigen, haben Sie die folgenden Optionen:

• SQLite Encryption Extension (SEE):Dies ist die offizielle Verschlüsselungsimplementierung des SQLite-Teams. Eine kostenpflichtige Lizenz ist erforderlich. Weitere Informationen finden Sie unter https://sqlite.org/com/see.html. NuGet-Pakete sind über den SQLite-Builddienst von SourceGear verfügbar.
• SQLCipher: Kaufen Sie unterstützte Builds von Zetetic, oder erstellen Sie den Open Source Code selbst.
• SQLite3 Multiple Ciphers: NuGet-Pakete sind über SQLite3MultipleCiphers-NuGet verfügbar.
  • Beim Verschlüsseln einer neuen Datenbank oder beim Öffnen einer vorhandenen Datenbank, die mit SQLCipher verschlüsselt wurde, müssen Sie das Verschlüsselungsschema im Verbindungszeichenfolge mithilfe von URI-Parametern konfigurieren, z. B. Data Source=file:example.db?cipher=sqlcipher&legacy=4;Password=<password>. Details finden Sie unter Wie eine vorhandene mit SQLCipher verschlüsselte Datenbank geöffnet wird .

Weitere Informationen finden Sie unter SQLite-Verschlüsselungsoptionen für die Verwendung mit SQLitePCLRaw und SQLitePCLRaw 3.0 Versionshinweisen.

Einige SQLitePCLRaw-Bundlepakete wurden entfernt.

Nachverfolgung von Issue 5108

Altes Verhalten

Zuvor boten die Pakete SQLitePCLRaw.bundle_sqlite3, SQLitePCLRaw.bundle_winsqlite3, SQLitePCLRaw.bundle_green und SQLitePCLRaw.bundle_e_sqlite3mc eine bequeme Möglichkeit zur Konfiguration von SQLitePCLRaw mit dem entsprechenden SQLite-Anbieter.

Neues Verhalten

Beginnend mit SQLitePCLRaw 3.0 (verwendet von Microsoft. Data.Sqlite 11.0), diese Bundlepakete wurden entfernt. Wenn Ihre Anwendung von einem dieser Bundles abhängig ist, müssen Sie nun auf das entsprechende Anbieterpaket verweisen und es explizit initialisieren.

Warum

Jedes dieser Paketpakete enthielt nur eine einzige Zeile von Konfigurationscode und zusätzlichen unnötigen Verpackungsaufwand. Die entsprechenden Anbieterpakete werden weiterhin unterstützt.

Gegenmaßnahmen

Ersetzen Sie das entfernte Bundlepaket durch das entsprechende Anbieterpaket, und fügen Sie expliziten Initialisierungscode hinzu.

Bei der Verwendung von bundle_sqlite3 oder bundle_winsqlite3, ersetzen Sie den Paketverweis:

<!-- Old -->
<PackageReference Include="SQLitePCLRaw.bundle_sqlite3" Version="2.x.x" />
<!-- or -->
<PackageReference Include="SQLitePCLRaw.bundle_winsqlite3" Version="2.x.x" />

<!-- New -->
<PackageReference Include="SQLitePCLRaw.provider.sqlite3" Version="3.x.x" />
<!-- or -->
<PackageReference Include="SQLitePCLRaw.provider.winsqlite3" Version="3.x.x" />

Fügen Sie dann vor der Verwendung von SQLite explizite Initialisierung hinzu:

// For sqlite3
static void Init()
{
    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_sqlite3());
}

// For winsqlite3
static void Init()
{
    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_winsqlite3());
}

Bei Verwendung von bundle_green wird empfohlen, auf SQLitePCLRaw.bundle_e_sqlite3 umzusteigen. Alternativ können Sie SQLitePCLRaw.config.e_sqlite3 zusammen mit einem separaten nativen Bibliothekspaket wie SourceGear.sqlite3 verwenden, mit dem Sie die SQLite-Version unabhängig aktualisieren können.

<PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.x.x" />

Wenn Sie nur auf iOS abzielen und die System SQLite-Bibliothek weiterhin verwenden möchten, verweisen Sie direkt auf den Anbieter:

<PackageReference Include="SQLitePCLRaw.core" Version="3.x.x" />
<PackageReference Include="SQLitePCLRaw.provider.sqlite3" Version="3.x.x" />

Und initialisieren Sie sie explizit:

static void Init()
{
    SQLitePCL.raw.SetProvider(new SQLitePCL.SQLite3Provider_sqlite3());
}