Modifiche di rilievo in EF Core 11 (EF11)

Questa pagina illustra le modifiche di comportamento e API che potrebbero interrompere l'aggiornamento delle applicazioni esistenti da EF Core 10 a EF Core 11. Assicurarsi di esaminare le modifiche di rilievo precedenti se si esegue l'aggiornamento da una versione precedente di EF Core:

• Modifiche di rilievo in EF Core 10
• Cambiamenti rilevanti in EF Core 9
• Modifiche importanti in EF Core 8

Riassunto

Modifiche a impatto medio

L'I/O di sincronizzazione tramite il provider di Azure Cosmos DB è stata completamente rimossa

Problema di rilevamento n. 37059

Comportamento precedente

L'I/O sincrono tramite il provider di Azure Cosmos DB non è supportato a partire da EF 9.0 (note); chiamando qualsiasi API di I/O sincrona, ad esempio ToList o SaveChanges ha generato un'eccezione, a meno che non sia stato configurato un consenso esplicito speciale. Quando è stato configurato l'opt-in, le API di I/O sincrone hanno funzionato come in precedenza, causando il blocco di tipo "sync-over-async" sull'SDK di Azure Cosmos DB, che potrebbe portare a deadlock e altri problemi di prestazioni.

Nuovo comportamento

A partire da EF Core 11.0, EF ora genera sempre quando viene chiamata un'API di I/O sincrona. Non è possibile tornare a utilizzare le API di I/O di sincronizzazione.

Perché

Il blocco sincrono sui metodi asincroni ("sincrono su asincrono") è altamente sconsigliato e può causare deadlock e altri problemi di prestazione. Poiché l'SDK di Azure Cosmos DB supporta solo metodi asincroni, anche il provider EF Cosmos fa lo stesso.

Mitigazioni

Convertire il codice in modo da usare api di I/O asincrone invece di sincronizzare quelle di I/O. Ad esempio, sostituire le chiamate a SaveChanges() con await SaveChangesAsync().

Microsoft. Data.SqlClient è stato aggiornato alla versione 7.0

Comportamento precedente

EF Core 10 ha usato Microsoft. Data.SqlClient 6.x, che includeva dipendenze di autenticazione Azure/Entra ID (ad esempio Azure.Core, Azure.Identity e Microsoft.Identity.Client) nel pacchetto principale.

Nuovo comportamento

EF Core 11 dipende ora da Microsoft. Data.SqlClient 7.0. Questa versione rimuove le dipendenze di autenticazione Azure/Entra ID (in precedenza Azure Active Directory) dal pacchetto principale. Se l'applicazione usa l'autenticazione Entra ID (ad esempio, ActiveDirectoryDefault, ActiveDirectoryInteractive, ActiveDirectoryManagedIdentity o ActiveDirectoryServicePrincipal), è ora necessario installare il pacchetto Microsoft.Data.SqlClient.Extensions.Azure separatamente.

Inoltre, SqlAuthenticationMethod.ActiveDirectoryPassword è stato contrassegnato come obsoleto.

Per altri dettagli, vedere le note sulla versione di Microsoft.Data.SqlClient 7.0.

Perché

Questa modifica è stata apportata in Microsoft. Data.SqlClient per ridurre il blob delle dipendenze per le applicazioni che non usano l'autenticazione Azure, particolarmente utile per le distribuzioni in contenitori e lo sviluppo locale.

Mitigazioni

Se l'applicazione usa l'autenticazione Entra ID con SQL Server, aggiungere un riferimento al pacchetto Microsoft.Data.SqlClient.Extensions.Azure nel progetto:

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

Non sono necessarie modifiche al codice oltre all'aggiunta di questo riferimento al pacchetto. Se si usa SqlAuthenticationMethod.ActiveDirectoryPassword, eseguire la migrazione a un metodo di autenticazione moderno, ActiveDirectoryDefault ad esempio o ActiveDirectoryInteractive.

Modifiche a basso impatto

EF Core ora genera un'eccezione per impostazione predefinita quando non vengono trovate migrazioni

Problema di rilevamento n. 35218

Comportamento precedente

In precedenza, quando si chiama Migrate o MigrateAsync su un database senza migrazioni nell'assembly, EF Core ha registrato un messaggio informativo e restituito senza applicare alcuna modifica.

Nuovo comportamento

A partire da EF Core 11.0, EF Core genera un'eccezione per impostazione predefinita quando non viene trovata alcuna migrazione nell'assembly. Questo comportamento è coerente con il PendingModelChangesWarning comportamento introdotto in EF 9.0.

Perché

La chiamata Migrate() o MigrateAsync() quando non esistono migrazioni indica in genere una configurazione errata. Anziché continuare in modo invisibile all'utente e lasciare il database in uno stato potenzialmente errato, EF Core avvisa ora gli sviluppatori di questo problema immediatamente.

Mitigazioni

Se si chiama Migrate() intenzionalmente senza eseguire migrazioni, ad esempio perché lo schema del database viene gestito tramite altri mezzi, rimuovere la Migrate() chiamata o eliminare l'eccezione configurando avvisi:

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

Oppure per registrare l'evento invece di generare:

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

EFOptimizeContext La proprietà MSBuild è stata rimossa

Problema di rilevamento n. 35079

Comportamento precedente

In precedenza, la proprietà MSBuild potrebbe essere impostata su EFOptimizeContext per abilitare la true generazione di codice di query compilata e precompilata durante la compilazione o la pubblicazione:

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

Nuovo comportamento

A partire da EF Core 11.0, la EFOptimizeContext proprietà MSBuild è stata rimossa. La generazione del codice è ora controllata esclusivamente tramite le EFScaffoldModelStage proprietà e EFPrecompileQueriesStage . Quando PublishAOT è impostato su true, la generazione del codice viene abilitata automaticamente durante la pubblicazione senza che sia necessaria alcuna proprietà aggiuntiva.

Perché

Le EFScaffoldModelStage proprietà e EFPrecompileQueriesStage forniscono già un controllo granulare su quando si verifica la generazione del codice. EFOptimizeContext era una porta di abilitazione ridondante.

Mitigazioni

Sostituire gli utilizzi di EFOptimizeContext con le proprietà EFScaffoldModelStage e EFPrecompileQueriesStage. Questi valori possono essere impostati su publish o build per controllare in quale fase si verifica la generazione del codice:

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

Qualsiasi altro valore ,ad esempio , nonedisabilita la generazione corrispondente.

Se è stato PublishAOT impostato su true, la generazione del codice viene abilitata automaticamente durante la pubblicazione e non è necessaria alcuna configurazione aggiuntiva.

I pacchetti degli strumenti di Entity Framework non fanno più riferimento a Microsoft.EntityFrameworkCore.Design

Problema di rilevamento n. 37739

Comportamento precedente

In precedenza, i pacchetti NuGet Microsoft.EntityFrameworkCore.Tools e Microsoft.EntityFrameworkCore.Tasks avevano una dipendenza da Microsoft.EntityFrameworkCore.Design.

Nuovo comportamento

A partire da EF Core 11.0, i pacchetti NuGet Microsoft.EntityFrameworkCore.Tools e Microsoft.EntityFrameworkCore.Tasks non hanno più una dipendenza da Microsoft.EntityFrameworkCore.Design.

Perché

Non esiste alcuna dipendenza rigida dal codice in Microsoft.EntityFrameworkCore.Design e questa dipendenza causava problemi durante l'uso dell'ultima Microsoft.EntityFrameworkCore.Tools con progetti destinati a framework meno recenti.

Mitigazioni

Se il tuo progetto si basa su Microsoft.EntityFrameworkCore.Design portato in modo transitivo attraverso i pacchetti degli strumenti, aggiungi un riferimento diretto ad esso nel tuo progetto:

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

Le proprietà SqlVector non vengono più caricate per impostazione predefinita

Problema di rilevamento n. 37279

Comportamento precedente

In precedenza, durante l'esecuzione di query sulle entità con le proprietà SqlVector<T>, EF Core includeva la colonna vettoriale nelle dichiarazioni SELECT e popolava la proprietà nell'entità restituita.

Nuovo comportamento

A partire da EF Core 11.0, le proprietà SqlVector<T> non sono più incluse nelle istruzioni SELECT al momento della materializzazione delle entità. La proprietà sarà null sulle entità restituite.

Le proprietà vettoriali possono comunque essere usate nelle clausole WHERE e ORDER BY — incluse con VectorDistance() e VectorSearch() — ma non saranno incluse nella proiezione delle entità.

Perché

Le colonne vettoriali possono essere molto grandi, contenenti centinaia o migliaia di valori a virgola mobile. Nella maggior parte dei casi, i vettori vengono scritti nel database e quindi usati per la ricerca, senza dover essere letti di nuovo. Escluderli da SELECT per impostazione predefinita evita il trasferimento inutile di dati.

Mitigazioni

Se è necessario leggere i valori del vettore indietro, usare una proiezione esplicita:

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

Cosmos: le raccolte di proprietà vuote restituiscono ora una raccolta vuota anziché null

Problema di rilevamento n. 36577

Comportamento precedente

In precedenza, durante l'esecuzione di query sulle entità tramite il provider Azure Cosmos DB, in cui una raccolta posseduta non conteneva elementi, la proprietà della raccolta era null sull'entità materializzata.

Nuovo comportamento

A partire da EF Core 11.0, il provider Azure Cosmos DB inizializza correttamente le raccolte di proprietà vuote, restituendo una raccolta vuota anziché null.

Perché

Il comportamento precedente di materializzare le collezioni possedute vuote come null era un bug.

Mitigazioni

Se il codice controlla esplicitamente le proprietà delle raccolte possedute per null verificare che la raccolta sia vuota, questi controlli possono essere semplicemente rimossi, poiché la raccolta è ora sempre inizializzata.

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

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

Microsoft. Modifiche che causano un'interruzione di Data.Sqlite

Riassunto

Modifiche a impatto medio

I pacchetti SQLite abilitati per la crittografia sono stati rimossi

Problema di rilevamento n. 5108

Comportamento precedente

In precedenza, il SQLitePCLRaw.bundle_e_sqlcipher pacchetto NuGet forniva build SQLite abilitate per la crittografia senza costi.

Nuovo comportamento

A partire da SQLitePCLRaw 3.0 (usato da Microsoft. Data.Sqlite 11.0), il pacchetto SQLitePCLRaw.bundle_e_sqlcipher è stato deprecato e rimosso da NuGet. Le compilazioni SQLite dotate di crittografia non vengono più distribuite.

Perché

Il precedente pacchetto senza costi SQLitePCLRaw.bundle_e_sqlcipher è stato mantenuto a malapena, che è un problema significativo per il software di crittografia in cui le vulnerabilità di sicurezza possono andare senza patch. Il manutentore SQLitePCLRaw ha rimosso queste build nella versione 3.0 a favore di alternative a pagamento gestite professionalmente che forniscono aggiornamenti della sicurezza continui.

Mitigazioni

Se è necessaria la crittografia SQLite, sono disponibili le opzioni seguenti:

• SQLite Encryption Extension (SEE): questa è l'implementazione ufficiale della crittografia del team SQLite. È necessaria una licenza a pagamento. Per informazioni dettagliate, vedere https://sqlite.org/com/see.html. I pacchetti NuGet sono disponibili tramite il servizio di compilazione SQLite di SourceGear.
• SQLCipher: acquistare build supportate da Zetetic oppure compilare il codice open source manualmente.
• SQLite3 Multiple Cifrature: i pacchetti NuGet sono disponibili da SQLite3MultipleCiphers-NuGet.
  • Quando si crittografa un nuovo database o si apre un database esistente crittografato con SQLCipher, è necessario configurare lo schema di crittografia nel stringa di connessione usando parametri URI, ad esempio Data Source=file:example.db?cipher=sqlcipher&legacy=4;Password=<password>. Per informazioni dettagliate, vedere Come aprire un database esistente crittografato con SQLCipher .

Per altre informazioni, vedere Le opzioni di crittografia SQLite per l'uso con SQLitePCLRaw e SQLitePCLRaw 3.0 Note sulla versione.

Alcuni pacchetti bundle SQLitePCLRaw sono stati rimossi

Problema di rilevamento n. 5108

Comportamento precedente

In precedenza, i pacchetti SQLitePCLRaw.bundle_sqlite3, SQLitePCLRaw.bundle_winsqlite3, SQLitePCLRaw.bundle_green e SQLitePCLRaw.bundle_e_sqlite3mc hanno fornito un modo pratico per configurare SQLitePCLRaw con il provider SQLite corrispondente.

Nuovo comportamento

A partire da SQLitePCLRaw 3.0 (usato da Microsoft. Data.Sqlite 11.0), questi pacchetti bundle sono stati rimossi. Se l'applicazione dipende da uno di questi bundle, è ora necessario fare riferimento al pacchetto del provider corrispondente e inizializzarlo in modo esplicito.

Perché

Ognuno di questi bundle conteneva solo una singola riga di codice di configurazione e aggiungeva un sovraccarico di imballaggio non necessario. I pacchetti di provider corrispondenti sono ancora supportati.

Mitigazioni

Sostituire il pacchetto bundle rimosso con il pacchetto del provider corrispondente e aggiungere codice di inizializzazione esplicito.

Se si usa bundle_sqlite3 o bundle_winsqlite3, sostituire il riferimento al pacchetto:

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

Aggiungere quindi l'inizializzazione esplicita prima di usare 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());
}

Se si usa bundle_green, il percorso di migrazione consigliato consiste nel passare a SQLitePCLRaw.bundle_e_sqlite3. In alternativa, usare SQLitePCLRaw.config.e_sqlite3 abbinato a un pacchetto di libreria nativa separato, ad SourceGear.sqlite3esempio , che consente di aggiornare la versione di SQLite in modo indipendente:

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

Se si usa solo iOS e si vuole continuare a usare la libreria SQLite di sistema, fare riferimento direttamente al provider:

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

Inizializzarlo in modo esplicito:

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