Skip to content
Open
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 49 additions & 2 deletions entity-framework/core/what-is-new/ef-core-11.0/breaking-changes.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
title: Breaking changes in EF Core 11 (EF11) - EF Core
description: List of breaking changes introduced in Entity Framework Core 11 (EF11)
author: roji
ms.date: 03/27/2026
ms.date: 06/11/2026
uid: core/what-is-new/ef-core-11.0/breaking-changes
---

Expand Down Expand Up @@ -122,7 +122,7 @@ If your application uses composite keys whose values can contain the characters

- **Existing data**: Documents previously stored in Cosmos DB have `id` values using the old escape sequences (e.g. `Post|1|^2F`). After upgrading to EF Core 11, EF will generate unescaped `id` values (e.g. `Post|1|/`) and will no longer find those existing documents. To continue accessing existing data without migration, opt back into the old behavior using the `AppContext` switch described above—however, be aware that the id-collision bug will still be present.

- **New data**: If you are creating a new application or database, avoid using these illegal characters in key values, as they are not valid in Cosmos DB resource `id` values. See the [Azure documentation](https://learn.microsoft.com/dotnet/api/microsoft.azure.documents.resource.id) for details.
- **New data**: If you are creating a new application or database, avoid using these illegal characters in key values, as they are not valid in Cosmos DB resource `id` values. See the [Azure documentation](/dotnet/api/microsoft.azure.documents.resource.id) for details.

## Low-impact changes

Expand Down Expand Up @@ -334,6 +334,7 @@ if (entity.OwnedCollection is { Count: 0 })
|:----------------------------------------------------------------------------------------------------------|------------|
| [Encryption-enabled SQLite packages have been removed](#sqlite-encryption-removed) | Medium |
| [Some SQLitePCLRaw bundle packages have been removed](#sqlite-bundles-removed) | Medium |
| [Microsoft.Data.Sqlite now bundles SQLite3 Multiple Ciphers](#sqlite-bundles-mc) | Low |

### Medium-impact changes

Expand Down Expand Up @@ -442,3 +443,49 @@ static void Init()

> [!NOTE]
> If you are using `SQLitePCLRaw.bundle_e_sqlite3`, no changes are required—just update the version number. See the [SQLitePCLRaw 3.0 Release Notes](https://github.com/ericsink/SQLitePCL.raw/blob/main/v3.md) for details.

### Low-impact changes

<a name="sqlite-bundles-mc"></a>

#### Microsoft.Data.Sqlite now bundles SQLite3 Multiple Ciphers

[Tracking PR dotnet/efcore#38402](https://github.com/dotnet/efcore/pull/38402)

##### Old behavior

The `Microsoft.Data.Sqlite` package referenced `SQLitePCLRaw.bundle_e_sqlite3`, which provides the standard `e_sqlite3` native SQLite build. This build has no encryption support, so setting a password (for example, via `SqliteConnectionStringBuilder.Password` or the `Password` connection-string keyword) failed at runtime.

##### New behavior

Starting with `Microsoft.Data.Sqlite` 11.0, the package references `SQLite3MC.PCLRaw.bundle`, which provides the `e_sqlite3mc` native build ([SQLite3 Multiple Ciphers](https://github.com/utelle/SQLite3MultipleCiphers)). This build receives updates—including upstream SQLite security fixes—on NuGet.org more promptly than `bundle_e_sqlite3`.
Comment thread
AndriySvyryd marked this conversation as resolved.
Outdated

As an added bonus, the new build is encryption-capable by default, so encryption (including setting a password) now works out of the box. See the [SQLite3 Multiple Ciphers documentation](https://github.com/utelle/SQLite3MultipleCiphers-NuGet#passphrase-based-database-encryption-support) for details on enabling passphrase-based database encryption.
Comment thread
AndriySvyryd marked this conversation as resolved.
Outdated

This change applies only to the `Microsoft.Data.Sqlite` package. In EF Core 11, the EF Core SQLite provider (`Microsoft.EntityFrameworkCore.Sqlite`) continues to reference `SQLitePCLRaw.bundle_e_sqlite3` rather than `SQLite3MC.PCLRaw.bundle` to preserve existing EF Core application behavior, since the provider doesn't expose SQLite encryption support.
Comment thread
AndriySvyryd marked this conversation as resolved.
Outdated

##### Why

The primary reason for the switch is maintenance and security: new versions of the `e_sqlite3` native build are no longer published to NuGet.org through `SQLitePCLRaw.bundle_e_sqlite3` in a timely manner, which means security fixes in upstream SQLite can be delayed. SQLite3 Multiple Ciphers is an actively maintained project that tracks upstream SQLite releases and ships updated builds promptly, so it was adopted as the default native build for `Microsoft.Data.Sqlite`. As an added bonus, it also restores a no-cost SQLite encryption option, which had been lost when the `SQLitePCLRaw.bundle_e_sqlcipher` package was deprecated and removed (see [Encryption-enabled SQLite packages have been removed](#sqlite-encryption-removed)).
Comment thread
AndriySvyryd marked this conversation as resolved.
Outdated

##### Mitigations

For most applications, **no action is required**. SQLite3 Multiple Ciphers is a superset of SQLite that behaves identically to the standard build for unencrypted databases—it only applies encryption when you explicitly supply a key or password. Existing unencrypted databases continue to open and work unchanged.

Review the following cases, which may require action in some applications:

- **Native library and provider name change.** The bundled native library is now `e_sqlite3mc` (rather than `e_sqlite3`), and the provider initialized by the bundle is `SQLite3Provider_e_sqlite3mc`. This matters if your application:
- References a specific native asset filename (for example, `e_sqlite3`) in publishing, trimming, AOT, or single-file configuration. Update those references to `e_sqlite3mc`.

- **Platform (RID) coverage.** SQLite3 Multiple Ciphers ships native binaries for a different set of runtime identifiers than `bundle_e_sqlite3`. If you target a platform that the new bundle doesn't include, the native library may fail to load at runtime. In that case, revert to the standard build as described below.
Comment thread
AndriySvyryd marked this conversation as resolved.
Outdated

- **Reserved encryption keywords.** SQLite3 Multiple Ciphers reserves certain connection-string/URI parameters and PRAGMAs (such as `key`, `hexkey`, and `cipher`) for encryption configuration. This is unlikely to affect typical applications, but if you happened to use these names for unrelated purposes, behavior may differ.

- **Double-quoted string literal support.** `e_sqlite3mc` doesn't include SQLite's legacy support for double-quoted string literals. If your SQL uses double quotes for string values, change it to use single quotes; double quotes should be used only for identifiers. Review raw SQL in your application (for example, SQL passed to `FromSql`, `ExecuteSql`, or migrations operations), and use SQL logging or integration tests to identify affected commands.

If you want to keep using the standard, non-encrypted `e_sqlite3` build, reference `Microsoft.Data.Sqlite.Core` together with `SQLitePCLRaw.bundle_e_sqlite3` instead of the `Microsoft.Data.Sqlite` meta-package:

```xml
<PackageReference Include="Microsoft.Data.Sqlite.Core" Version="11.0.0" />
<PackageReference Include="SQLitePCLRaw.bundle_e_sqlite3" Version="3.x.x" />
```