Belangrijke wijzigingen in EF Core 11 (EF11)

Op deze pagina worden API's en gedragswijzigingen beschreven die het potentieel hebben om bestaande toepassingen te onderbreken die worden bijgewerkt van EF Core 10 naar EF Core 11. Controleer eerdere belangrijke wijzigingen als u een eerdere versie van EF Core bijwerkt:

• Belangrijke wijzigingen in EF Core 10
• Belangrijke wijzigingen in EF Core 9
• Ingrijpende wijzigingen in EF Core 8

Samenvatting

Wijzigingen met gemiddelde impact

Synchronisatie-I/O via de Azure Cosmos DB-provider is volledig verwijderd

Traceringsprobleem #37059

Oud gedrag

Synchrone I/O via de Azure Cosmos DB-provider wordt niet ondersteund sinds EF 9.0 (note); het aanroepen van een synchronisatie-I/O-API, zoals ToList of SaveChanges heeft een uitzondering veroorzaakt, tenzij er een speciale opt-in is geconfigureerd. Toen de opt-in werd geconfigureerd, werkten I/O-API's voor synchronisatie als voorheen, waardoor de provider 'sync-over-async' blokkeerde bij de Azure Cosmos DB SDK, wat tot impasses en andere prestatieproblemen kan leiden.

Nieuw gedrag

Vanaf EF Core 11.0 genereert EF nu altijd wanneer een synchrone I/O-API wordt aangeroepen. U kunt zich niet opnieuw aanmelden voor het gebruik van I/O-API's voor synchronisatie.

Waarom

Het is sterk afgeraden om synchrone blokkering toe te passen op asynchrone methoden ("sync-over-async"), aangezien dit kan leiden tot deadlocks en andere prestatieproblemen. Omdat de Azure Cosmos DB SDK alleen asynchrone methoden ondersteunt, ondersteunt de EF Cosmos-provider dat ook.

Maatregelen

Converteer uw code om asynchrone I/O-API's te gebruiken in plaats van I/O-api's te synchroniseren. Vervang bijvoorbeeld aanroepen van SaveChanges() door await SaveChangesAsync().

Microsoft. Data.SqlClient is bijgewerkt naar 7.0

Oud gedrag

EF Core 10 gebruikt Microsoft. Data.SqlClient 6.x, waaronder Azure/Entra ID verificatieafhankelijkheden (zoals Azure.Core, Azure.Identity en Microsoft.Identity.Client) in het kernpakket.

Nieuw gedrag

EF Core 11 is nu afhankelijk van Microsoft. Data.SqlClient 7.0. Met deze versie worden Azure/Entra ID (voorheen Azure Active Directory) verificatieafhankelijkheden uit het kernpakket verwijderd. Als uw toepassing gebruikmaakt van Entra ID-verificatie (bijvoorbeeld ActiveDirectoryDefault, ActiveDirectoryInteractive, ActiveDirectoryManagedIdentity of ActiveDirectoryServicePrincipal), moet u nu het Microsoft.Data.SqlClient.Extensions.Azure-pakket afzonderlijk installeren.

Bovendien SqlAuthenticationMethod.ActiveDirectoryPassword is gemarkeerd als verouderd.

Zie de releaseopmerkingen voor Microsoft.Data.SqlClient 7.0 voor meer informatie.

Waarom

Deze wijziging is aangebracht in Microsoft. Data.SqlClient om afhankelijkheidsbloat te verminderen voor toepassingen die geen gebruikmaken van Azure-verificatie, wat met name nuttig is voor implementaties in containers en lokale ontwikkeling.

Maatregelen

Als uw toepassing gebruikmaakt van Entra ID-verificatie met SQL Server, voegt u een verwijzing toe naar het Microsoft.Data.SqlClient.Extensions.Azure-pakket in uw project:

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

Er zijn geen codewijzigingen vereist, behalve het toevoegen van deze pakketreferentie. Als u SqlAuthenticationMethod.ActiveDirectoryPassword gebruikt, migreer naar een moderne verificatiemethode, zoals ActiveDirectoryDefault of ActiveDirectoryInteractive.

Wijzigingen met lage impact

EF Core geeft nu standaard een foutmelding als er geen migraties worden gevonden.

Traceringsprobleem #35218

Oud gedrag

Voorheen, bij het aanroepen of Migrate opvragen MigrateAsync van een database zonder migraties in de assembly, heeft EF Core een informatief bericht geregistreerd en geretourneerd zonder wijzigingen toe te passen.

Nieuw gedrag

Vanaf EF Core 11.0 genereert EF Core standaard een uitzondering wanneer er geen migraties in de assembly worden gevonden. Dit is consistent met het PendingModelChangesWarning gedrag dat is geïntroduceerd in EF 9.0.

Waarom

Aanroepen Migrate() of MigrateAsync() wanneer er geen migraties bestaan duidt meestal op een onjuiste configuratie. In plaats van op de achtergrond door te gaan en de database in een mogelijk onjuiste status te laten staan, waarschuwt EF Core ontwikkelaars nu onmiddellijk voor dit probleem.

Maatregelen

Als u opzettelijk aanroept Migrate() zonder migraties te hebben (bijvoorbeeld omdat u het databaseschema op een andere manier beheert), verwijdert u de Migrate() aanroep of onderdrukt u de uitzondering door waarschuwingen te configureren:

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

Of als u de gebeurtenis wilt vastleggen in plaats van te gooien:

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

EFOptimizeContext De eigenschap MSBuild is verwijderd

Trackeringsprobleem #35079

Oud gedrag

Voorheen kon de EFOptimizeContext MSBuild-eigenschap worden ingesteld op true om de generatie van gecompileerde modellen en vooraf gecompileerde querycode tijdens het bouwen of publiceren in te schakelen.

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

Nieuw gedrag

Vanaf EF Core 11.0 is de EFOptimizeContext eigenschap MSBuild verwijderd. Het genereren van code wordt nu uitsluitend beheerd via de EFScaffoldModelStage en EFPrecompileQueriesStage eigenschappen. Wanneer PublishAOT op true is ingesteld, wordt het genereren van code automatisch ingeschakeld tijdens het publiceren zonder dat er een extra eigenschap nodig is.

Waarom

De EFScaffoldModelStage eigenschappen en EFPrecompileQueriesStage eigenschappen bieden al nauwkeurige controle over wanneer codegeneratie plaatsvindt. EFOptimizeContext was een redundante inschakelingspoort.

Maatregelen

Vervang het gebruik van EFOptimizeContext met de EFScaffoldModelStage en EFPrecompileQueriesStage eigenschappen. Deze kunnen worden ingesteld op publish of build om te bepalen in welke fase codegeneratie plaatsvindt:

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

Elke andere waarde (bijvoorbeeld none) schakelt de bijbehorende generatie uit.

Als u PublishAOT op true hebt ingesteld, wordt codegeneratie automatisch ingeschakeld tijdens het publiceren en is er geen aanvullende configuratie nodig.

EF-hulpprogrammapakketten verwijzen niet langer naar Microsoft.EntityFrameworkCore.Design

Volgkwestie #37739

Oud gedrag

Voorheen hadden de Microsoft.EntityFrameworkCore.Tools en Microsoft.EntityFrameworkCore.Tasks NuGet-pakketten een afhankelijkheid van Microsoft.EntityFrameworkCore.Design.

Nieuw gedrag

Vanaf EF Core 11.0 hebben de Microsoft.EntityFrameworkCore.Tools en Microsoft.EntityFrameworkCore.Tasks NuGet-pakketten geen afhankelijkheid meer van Microsoft.EntityFrameworkCore.Design.

Waarom

Er was geen vaste afhankelijkheid van de code in Microsoft.EntityFrameworkCore.Design en deze afhankelijkheid veroorzaakte problemen bij het gebruik van de nieuwste Microsoft.EntityFrameworkCore.Tools met projecten die zijn gericht op oudere frameworks.

Maatregelen

Als uw project afhankelijk is van Microsoft.EntityFrameworkCore.Design dat transitief is opgenomen via de tools-pakketten, voeg er dan een directe verwijzing naar toe in uw project.

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

SqlVector-eigenschappen worden niet meer standaard geladen

Traceringsprobleem #37279

Oud gedrag

Voorheen bevatte EF Core bij het uitvoeren van query's op entiteiten met SqlVector<T> eigenschappen de vectorkolom in SELECT instructies en vulde de eigenschap op de geretourneerde entiteit in.

Nieuw gedrag

Vanaf EF Core 11.0 worden SqlVector<T> eigenschappen niet meer opgenomen in SELECT instructies wanneer entiteiten gematerialiseerd worden. De eigenschap bevindt zich null op geretourneerde entiteiten.

Vectoreigenschappen kunnen nog steeds worden gebruikt in WHERE en ORDER BY clausules, inclusief met VectorDistance() en VectorSearch(); ze worden alleen niet opgenomen in de entiteitsprojectie.

Waarom

Vectorkolommen kunnen erg groot zijn, met honderden of duizenden drijvendekommawaarden. In de meeste gevallen worden vectoren naar de database geschreven en vervolgens gebruikt voor zoekopdrachten, zonder dat ze hoeven te worden teruggelezen. Door deze standaard uit te sluiten bij SELECT, voorkomt u onnodige gegevensoverdracht.

Maatregelen

Als u vectorwaarden wilt lezen, gebruikt u een expliciete projectie:

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

Cosmos: lege verzamelingen in eigendom retourneren nu een lege verzameling in plaats van null

Traceringsprobleem #36577

Oud gedrag

Bij de vorige uitvoering van query's op entiteiten via de Azure Cosmos DB-provider, waarbij een toegewezen collectie geen items bevatte, werd de collectie-eigenschap als null op de materiaalgegevensentiteit weergegeven.

Nieuw gedrag

Vanaf EF Core 11.0 initialiseert de Azure Cosmos DB-provider lege verzamelingen correct, waarbij een lege verzameling wordt geretourneerd in plaats van null.

Waarom

Het eerdere gedrag van het materialiseren van lege eigendomlijke verzamelingen als null was een bug.

Maatregelen

Als uw code expliciet de eigenschappen null van de verzameling controleert om te detecteren dat de verzameling leeg is, kunnen deze controles eenvoudig worden verwijderd, omdat de verzameling nu altijd wordt geïnitialiseerd:

// 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 ingrijpende wijzigingen

Samenvatting

Wijzigingen met gemiddelde impact

SqLite-pakketten met versleuteling zijn verwijderd

Volgprobleem #5108

Oud gedrag

Voorheen bood het SQLitePCLRaw.bundle_e_sqlcipher NuGet-pakket sqlite-builds waarvoor versleuteling is ingeschakeld, gratis.

Nieuw gedrag

Beginnend met SQLitePCLRaw 3.0 (gebruikt door Microsoft. Data.Sqlite 11.0), het SQLitePCLRaw.bundle_e_sqlcipher-pakket is afgeschaft en verwijderd uit NuGet. SqLite-builds die zijn voorzien van versleuteling en waarvoor geen kosten in rekening worden gebracht, worden niet meer gedistribueerd.

Waarom

Het vorige pakket zonder kosten SQLitePCLRaw.bundle_e_sqlcipher werd nauwelijks onderhouden. Dit is een belangrijke zorg voor versleutelingssoftware waarbij beveiligingsproblemen mogelijk niet worden gepatcht. De SQLitePCLRaw-onderhouder heeft deze builds verwijderd in versie 3.0 ten gunste van professioneel onderhouden, betaalde alternatieven die doorlopende beveiligingsupdates bieden.

Maatregelen

Als u SQLite-versleuteling nodig hebt, hebt u de volgende opties:

• SQLite Encryption Extension (SEE):dit is de officiële versleutelingsimplementatie van het SQLite-team. Er is een betaalde licentie vereist. Zie https://sqlite.org/com/see.html voor meer informatie. NuGet-pakketten zijn beschikbaar via de SQLite-buildservice van SourceGear.
• SQLCipher: Koop ondersteunde builds van Zetetic of bouw de open source code zelf.
• SQLite3 Multiple Ciphers: NuGet-pakketten zijn beschikbaar via SQLite3MultipleCiphers-NuGet.
  • Wanneer u een nieuwe database versleutelt of een bestaande database opent die is versleuteld met SQLCipher, moet u het coderingsschema configureren in de verbindingsreeks met behulp van URI-parameters, bijvoorbeeld: Data Source=file:example.db?cipher=sqlcipher&legacy=4;Password=<password>. Zie Een bestaande database openen die is versleuteld met SQLCipher voor meer informatie.

Zie SQLite-versleutelingsopties voor gebruik met SQLitePCLRaw en SQLitePCLRaw 3.0 Releaseopmerkingen voor meer informatie.

Sommige SQLitePCLRaw-bundelpakketten zijn verwijderd

Volgprobleem #5108

Oud gedrag

Voorheen bieden de SQLitePCLRaw.bundle_sqlite3, SQLitePCLRaw.bundle_winsqlite3en SQLitePCLRaw.bundle_greenSQLitePCLRaw.bundle_e_sqlite3mc pakketten een handige manier om SQLitePCLRaw te configureren met de bijbehorende SQLite-provider.

Nieuw gedrag

Beginnend met SQLitePCLRaw 3.0 (gebruikt door Microsoft. Data.Sqlite 11.0), deze bundelpakketten zijn verwijderd. Als uw toepassing afhankelijk is van een van deze bundels, moet u nu verwijzen naar het bijbehorende providerpakket en deze expliciet initialiseren.

Waarom

Elk van deze bundelpakketten bevatte slechts één regel configuratiecode en heeft onnodige verpakkingsoverhead toegevoegd. De bijbehorende providerpakketten worden nog steeds ondersteund.

Maatregelen

Vervang het verwijderde bundelpakket door het bijbehorende providerpakket en voeg expliciete initialisatiecode toe.

Als u bundle_sqlite3 of bundle_winsqlite3 gebruikt, vervang de pakketreferentie:

<!-- 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" />

Voeg vervolgens expliciete initialisatie toe voordat u SQLite gebruikt:

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

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

Als u dit gebruikt bundle_green, is het aanbevolen migratiepad over te schakelen naar SQLitePCLRaw.bundle_e_sqlite3. U kunt ook SQLitePCLRaw.config.e_sqlite3 gebruiken in combinatie met een afzonderlijk native bibliotheekpakket zoals SourceGear.sqlite3, waardoor u de SQLite-versie onafhankelijk kunt bijwerken.

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

Als u alleen iOS wilt gebruiken en de sqlite-bibliotheek van het systeem wilt blijven gebruiken, verwijst u rechtstreeks naar de provider:

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

En initialiseer deze expliciet:

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