Oförenliga ändringar i EF Core 11 (EF11)

Den här sidan dokumenterar API och beteendeändringar som kan bryta befintliga program som uppdateras från EF Core 10 till EF Core 11. Se till att gå igenom tidigare större ändringar om du uppdaterar från en tidigare version av EF Core.

• Brytande ändringar i EF Core 10
• Störande ändringar i EF Core 9
• Icke-bakåtkompatibla ändringar i EF Core 8

Sammanfattning

Ändringar med medelpåverkan

Synkronisering av I/O via Azure Cosmos DB-providern har helt och hållet tagits bort.

Spårningsproblem #37059

Gammalt beteende

Synkront I/O via Azure Cosmos DB-leverantören har inte stötts sedan EF 9.0 (note); att anropa alla synkrona I/O-API:er, till exempel ToList eller SaveChanges, utlöste ett undantag, såvida inte ett särskilt opt-in konfigurerades. När opt-in konfigurerades fungerade synkroniserings-I/O-API:er som tidigare, vilket gjorde att providern utförde "sync-over-async"-blockering mot Azure Cosmos DB SDK, vilket kan leda till dödlägen och andra prestandaproblem.

Nytt beteende

Från och med EF Core 11.0 genererar EF nu alltid när ett synkront I/O-API anropas. Det finns inget sätt att återgå till att använda synkroniserings-I/O-API:er.

Varför

Synkron blockering på asynkrona metoder ("sync-over-async") är starkt avskräckande och kan leda till dödläge och andra prestandaproblem. Eftersom Azure Cosmos DB SDK endast stöder asynkrona metoder, så gör ÄVEN EF Cosmos-providern.

Åtgärder

Konvertera koden till att använda asynkrona I/O-API:er i stället för synkronisering av I/O-api:er. Ersätt till exempel anrop till SaveChanges() med await SaveChangesAsync().

Microsoft. Data.SqlClient har uppdaterats till 7.0

Gammalt beteende

EF Core 10 använde Microsoft.Data.SqlClient 6.x, som inkluderade Azure/Entra ID-autentiseringsberoenden (till exempel Azure.Core, Azure.Identity och Microsoft.Identity.Client) i kärnpaketet.

Nytt beteende

EF Core 11 är nu beroende av Microsoft. Data.SqlClient 7.0. Den här versionen tar bort autentiseringsberoenden för Azure/Entra ID (tidigare Azure Active Directory) från kärnpaketet. Om ditt program använder Entra ID autentisering (till exempel ActiveDirectoryDefault, ActiveDirectoryInteractive, ActiveDirectoryManagedIdentity eller ActiveDirectoryServicePrincipal) måste du nu installera paketet Microsoft.Data.SqlClient.Extensions.Azure separat.

Dessutom SqlAuthenticationMethod.ActiveDirectoryPassword har markerats som föråldrad.

För mer information, se releasenoter för Microsoft.Data.SqlClient 7.0.

Varför

Den här ändringen gjordes i Microsoft. Data.SqlClient för att minska beroendets uppsvälldhet för program som inte använder Azure autentisering, vilket är särskilt fördelaktigt för containerbaserade distributioner och lokal utveckling.

Åtgärder

Om programmet använder Entra ID autentisering med SQL Server lägger du till en referens till paketet Microsoft.Data.SqlClient.Extensions.Azure i projektet:

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

Inga kodändringar krävs utöver att lägga till den här paketreferensen. Om du använder SqlAuthenticationMethod.ActiveDirectoryPasswordmigrerar du till en modern autentiseringsmetod som ActiveDirectoryDefault eller ActiveDirectoryInteractive.

Ändringar med låg påverkan

EF Core genererar nu som standard när inga migreringar hittas

Spårningsproblem #35218

Gammalt beteende

Tidigare, när du anropar Migrate eller MigrateAsync på en databas utan migreringar i sammansättningen, loggade EF Core ett informationsmeddelande och returnerade utan att tillämpa några ändringar.

Nytt beteende

Från och med EF Core 11.0 utlöser EF Core ett undantag som standard när inga migreringar hittas i sammansättningen. Detta överensstämmer med det beteende som PendingModelChangesWarningintroducerades i EF 9.0.

Varför

Att anropa Migrate() eller MigrateAsync() när det inte finns några migreringar indikerar vanligtvis en felkonfiguration. I stället för att tyst fortsätta och lämna databasen i ett potentiellt felaktigt tillstånd varnar EF Core nu utvecklare om det här problemet omedelbart.

Åtgärder

Om du avsiktligt anropar Migrate() utan att ha några migreringar (till exempel för att du hanterar databasschemat på annat sätt) tar du bort anropet Migrate() eller undertrycker undantaget genom att konfigurera varningar:

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

Eller för att logga händelsen i stället för att kasta:

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

EFOptimizeContext MSBuild-egenskapen har tagits bort

Spårningsproblem #35079

Gammalt beteende

EFOptimizeContext Tidigare kunde egenskapen MSBuild ställas in på för att true aktivera kompilerad modell och förkompilerad frågekodgenerering under kompilering eller publicering:

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

Nytt beteende

Från och med EF Core 11.0 EFOptimizeContext har egenskapen MSBuild tagits bort. Kodgenereringen styrs nu uteslutande via EFScaffoldModelStage egenskaperna och EFPrecompileQueriesStage . När PublishAOT är inställt på trueaktiveras kodgenerering automatiskt under publiceringen utan att någon ytterligare egenskap behövs.

Varför

Egenskaperna EFScaffoldModelStage och EFPrecompileQueriesStage ger redan detaljerad kontroll över när kodgenereringen inträffar. EFOptimizeContext var en överflödig aktiveringsport.

Åtgärder

Ersätt användning av EFOptimizeContext med EFScaffoldModelStage egenskaperna och EFPrecompileQueriesStage . Dessa kan ställas in på publish eller build för att styra vid vilken fas kodgenereringen sker:

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

Alla andra värden (till exempel none) inaktiverar motsvarande generering.

Om du har PublishAOT angett till trueaktiveras kodgenerering automatiskt under publiceringen och ingen ytterligare konfiguration krävs.

EF-verktygspaket refererar inte längre till Microsoft.EntityFrameworkCore.Design

Spårningsproblem #37739

Gammalt beteende

Tidigare hade nuGet-paketen Microsoft.EntityFrameworkCore.Tools och Microsoft.EntityFrameworkCore.Tasks ett beroende av Microsoft.EntityFrameworkCore.Design.

Nytt beteende

Från och med EF Core 11.0 har Microsoft.EntityFrameworkCore.Tools- och Microsoft.EntityFrameworkCore.Tasks NuGet-paketen inte längre något beroende av Microsoft.EntityFrameworkCore.Design.

Varför

Det fanns inget hårt beroende av koden i Microsoft.EntityFrameworkCore.Design, och det här beroendet orsakade problem när du använde den senaste Microsoft.EntityFrameworkCore.Tools med projekt som riktar sig till äldre ramverk.

Åtgärder

Om projektet förlitar sig på att Microsoft.EntityFrameworkCore.Design överförs via verktygspaketen lägger du till en direkt referens till det i projektet:

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

SqlVector-egenskaper läses inte längre in som standard

Spårningsproblem #37279

Gammalt beteende

Tidigare, när du frågar entiteter med SqlVector<T> egenskaper, inkluderade EF Core vektorkolumnen i SELECT -instruktioner och fyllde egenskapen på den returnerade entiteten.

Nytt beteende

Från och med EF Core 11.0 SqlVector<T> ingår inte längre egenskaper i SELECT instruktioner när entiteter materialiseras. Egenskapen kommer att vara null i returnerade entiteter.

Vektoregenskaper kan fortfarande användas i WHERE och ORDER BY -satser– inklusive med VectorDistance() och VectorSearch()– de tas bara inte med i entitetsprognosen.

Varför

Vektorkolumner kan vara mycket stora och innehålla hundratals eller tusentals flyttalsvärden. I de allra flesta fall skrivs vektorer till databasen och används sedan för sökning, utan att behöva läsas tillbaka. Om du utesluter dem från SELECT som standard undviks onödig dataöverföring.

Åtgärder

Om du behöver läsa tillbaka vektorvärden använder du en explicit projektion:

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

Cosmos: tomma ägda samlingar returnerar nu en tom samling i stället för null

Spårningsproblem #36577

Gammalt beteende

Tidigare, när du frågar entiteter via Azure Cosmos DB-providern där en ägd samling inte innehöll några objekt, var samlingsegenskapen null på den materialiserade entiteten.

Nytt beteende

Från och med EF Core 11.0 initierar Azure Cosmos DB-providern korrekt tomma ägda samlingar och returnerar en tom samling i stället för null.

Varför

Det tidigare beteendet att materialisera tomma ägda samlingar som null var en bugg.

Åtgärder

Om din kod uttryckligen kontrollerar egenskaper hos ägda samlingar för att identifiera att samlingen är tom kan dessa kontroller helt enkelt tas bort, eftersom samlingen nu alltid är initierad.

// 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- icke-bakåtkompatibla ändringar

Sammanfattning

Ändringar med medelpåverkan

Krypteringsaktiverade SQLite-paket har tagits bort

Spårningsproblem #5108

Gammalt beteende

SQLitePCLRaw.bundle_e_sqlcipher Tidigare tillhandahöll NuGet-paketet krypteringsaktiverade SQLite-versioner utan kostnad.

Nytt beteende

Från och med SQLitePCLRaw 3.0 (som används av Microsoft.Data.Sqlite 11.0) har paketet SQLitePCLRaw.bundle_e_sqlcipher förklarats föråldrat och tagits bort från NuGet. Krypteringsaktiverade SQLite-versioner utan kostnad distribueras inte längre.

Varför

Det tidigare kostnadsfria SQLitePCLRaw.bundle_e_sqlcipher-paketet underhölls knappt, vilket är ett betydande problem för krypteringsprogramvara där säkerhetsbrister kan förbli oåtgärdade. SQLitePCLRaw-underhållaren tog bort dessa versioner i version 3.0 till förmån för professionellt underhållna, betalda alternativ som ger löpande säkerhetsuppdateringar.

Åtgärder

Om du behöver SQLite-kryptering har du följande alternativ:

• SQLite Encryption Extension (SEE): Det här är den officiella krypteringsimplementeringen från SQLite-teamet. En betald licens krävs. Se https://sqlite.org/com/see.html för mer information. NuGet-paket är tillgängliga via SourceGears SQLite-byggtjänst.
• SQLCipher: Köp versioner som stöds från Zetetic eller skapa koden open-source själv.
• SQLite3 Flera chiffer: NuGet-paket är tillgängliga från SQLite3MultipleCiphers-NuGet.
  • När du krypterar en ny databas eller öppnar en befintlig databas som har krypterats med SQLCipher måste du konfigurera chifferschemat i reťazec pripojenia med hjälp av URI-parametrar, till exempel: Data Source=file:example.db?cipher=sqlcipher&legacy=4;Password=<password>. Mer information finns i Så här öppnar du en befintlig databas som krypterats med SQLCipher .

Mer information finns i SQLite-krypteringsalternativ för användning med SQLitePCLRaw och SQLitePCLRaw 3.0 Viktig information.

Vissa SQLitePCLRaw-paketpaket har tagits bort

Spårningsproblem #5108

Gammalt beteende

Tidigare var paketen SQLitePCLRaw.bundle_sqlite3, SQLitePCLRaw.bundle_winsqlite3, SQLitePCLRaw.bundle_greenoch SQLitePCLRaw.bundle_e_sqlite3mc ett bekvämt sätt att konfigurera SQLitePCLRaw med motsvarande SQLite-provider.

Nytt beteende

Från och med SQLitePCLRaw 3.0 (som används av Microsoft.Data.Sqlite 11.0) har dessa bundlar tagits bort. Om ditt program var beroende av något av dessa paket måste du nu referera till motsvarande providerpaket och uttryckligen initiera det.

Varför

Vart och ett av dessa paketpaket innehöll endast en enda rad konfigurationskod och lade till onödiga paketeringskostnader. Motsvarande providerpaket stöds fortfarande.

Åtgärder

Ersätt det borttagna paketpaketet med motsvarande providerpaket och lägg till explicit initieringskod.

Om du använder bundle_sqlite3 eller bundle_winsqlite3ersätter du paketreferensen:

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

Lägg sedan till explicit initiering innan du använder SQLite:

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

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

Om du använder bundle_greenär den rekommenderade migreringssökvägen att växla till SQLitePCLRaw.bundle_e_sqlite3. Alternativt kan du använda SQLitePCLRaw.config.e_sqlite3 parkopplat med ett separat internt bibliotekspaket som SourceGear.sqlite3, som gör att du kan uppdatera SQLite-versionen oberoende av varandra:

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

Om du bara riktar in dig på iOS och vill fortsätta använda systemets SQLite-bibliotek refererar du direkt till providern:

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

Och initiera det tydligt:

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