EF Core 11 Breaking Changes: 6 Upgrade Errors and Fixes

Last updated: October 25, 2026 · Tested with EF Core 11 RC2 (11.0.0-rc.2.26504.105) on .NET 11 RC2 against EF Core 10.0.13 on .NET 10.0.12, SQL Server 2019 and 2025 (LocalDB), SQLite, Windows 11

Short answer: upgrading a small EF Core 10 app to EF Core 11 broke in six places for me. Two fail before anything runs (EF Core 11 packages don’t install on net10.0, and dotnet ef refuses to work without the Design package). Two throw at runtime (queries using Math.Max/Math.Min fail on SQL Server 2019 with 'GREATEST' is not a recognized built-in function name, and Migrate() throws when there are no migrations). One is a new warning for owned JSON collections, and one drops .NET Framework support from Microsoft.Data.Sqlite. Each section has the exact message, the code that triggers it and the fix I ran.

#	What you will see	Cause	Fix
1	NU1202: Package Microsoft.EntityFrameworkCore.SqlServer 11.0.0 ... is not compatible with net10.0	EF Core 11 ships only a net11.0 build	Move the project to net11.0 first
2	SqlException: 'GREATEST' is not a recognized built-in function name.	Default SQL Server compatibility level is now 160 (SQL Server 2022)	UseCompatibilityLevel(150) on SQL Server 2019
3	InvalidOperationException: An error was generated for warning '...MigrationsNotFound'	Migrate() with no migrations is now an error	Add a migration, or ignore RelationalEventId.MigrationsNotFound
4	Your startup project ... doesn't reference Microsoft.EntityFrameworkCore.Design	The Tools package no longer brings Design	Reference Microsoft.EntityFrameworkCore.Design
5	warn: RelationalEventId.OwnedEntityMappedToJsonCollectionWarning[20613]	Owned JSON collections are obsolete	ComplexCollection(..., b => b.ToJson())
6	NU1202: Package Microsoft.Data.Sqlite 11.0.0 ... is not compatible with net48	Microsoft.Data.Sqlite 11 supports only net10.0 and later	Stay on 10.0.x for .NET Framework apps

How I Tested It

One console project builds against both versions from the same source. A Directory.Build.props switches the target framework and the EF Core package version with one property:

<TF Condition="'$(TF)' == ''">net10.0</TF>
<TargetFramework>$(TF)</TargetFramework>
<ExtVersion Condition="'$(TF)' == 'net10.0'">10.0.13</ExtVersion>
<ExtVersion Condition="'$(TF)' == 'net11.0'">11.0.0-rc.2.26504.105</ExtVersion>

The project references Microsoft.EntityFrameworkCore.SqlServer and Microsoft.EntityFrameworkCore.Sqlite at $(ExtVersion). “Before” runs used the .NET 10 SDK (dotnet run -p:TF=net10.0), “after” runs the .NET 11 RC2 SDK (dotnet run -p:TF=net11.0). For SQL Server I used two LocalDB instances: 2019 (15.0) and 2025 (17.0). All output below is copied from those runs.

1. NU1202: EF Core 11 Is Not Compatible with net10.0

EF Core 10 shipped for net10.0, and earlier versions often ran on the previous .NET too, so it is tempting to bump only the packages. With EF Core 11 that fails at restore:

error NU1202: Package Microsoft.EntityFrameworkCore.SqlServer 11.0.0-rc.2.26504.105 is not compatible with net10.0 (.NETCoreApp,Version=v10.0). Package Microsoft.EntityFrameworkCore.SqlServer 11.0.0-rc.2.26504.105 supports: net11.0 (.NETCoreApp,Version=v11.0)
error NU1202: Package Microsoft.EntityFrameworkCore.Sqlite 11.0.0-rc.2.26504.105 is not compatible with net10.0 (.NETCoreApp,Version=v10.0). Package Microsoft.EntityFrameworkCore.Sqlite 11.0.0-rc.2.26504.105 supports: net11.0 (.NETCoreApp,Version=v11.0)

The packages contain only a lib/net11.0 folder. Change <TargetFramework> to net11.0 first, then the packages. If your Dependabot or Renovate config updates EF Core on its own, pin it to 10.x until the app itself moves. For everything else that breaks when the framework moves, see Upgrading to .NET 11: 9 breaking changes and fixes.

2. ‘GREATEST’ Is Not a Recognized Built-in Function Name

This one compiles and passes every test that runs against a newer SQL Server or SQLite, then fails in production on an older server. EF Core 11 assumes SQL Server compatibility level 160 (SQL Server 2022) unless you tell it otherwise, so it uses newer T-SQL functions. A query like this:

var query = db.Products.Select(p => Math.Max(p.Price, p.MinPrice));
Console.WriteLine(query.ToQueryString());
var prices = await query.ToListAsync();

On EF Core 10 the Math.Max runs on the client and the SQL just reads both columns:

== SQL Server 2019, default compatibility level
SELECT [p].[Price], [p].[MinPrice]
FROM [Products] AS [p]
   result: 49.90

EF Core 11 translates it to GREATEST, which SQL Server 2019 doesn’t have:

== SQL Server 2019, default compatibility level
SELECT GREATEST([p].[Price], [p].[MinPrice])
FROM [Products] AS [p]
   SqlException: 'GREATEST' is not a recognized built-in function name.

The same EF Core 11 query against SQL Server 2025 works and returns 49.90. The fix is to tell EF Core which level your database really runs at:

var options = new DbContextOptionsBuilder<ShopDb>()
    .UseSqlServer(connectionString, o => o.UseCompatibilityLevel(150))
    .Options;

== SQL Server 2019, UseCompatibilityLevel(150)
SELECT [p].[Price], [p].[MinPrice]
FROM [Products] AS [p]
   result: 49.90

In an ASP.NET Core app the same option goes into AddDbContext: options.UseSqlServer(cs, o => o.UseCompatibilityLevel(150)). Use 150 for SQL Server 2019 and 140 for 2017. To check what a database runs at, SELECT compatibility_level FROM sys.databases WHERE name = DB_NAME();. Note that a SQL Server 2022 instance can still host a database at level 150 after a restore, and the database level is the one that counts.

Math.Max and Math.Min are the easiest way to hit this, but they are not the only queries whose SQL depends on the level, so set it once in the options rather than rewriting queries.

3. Migrate() Throws When There Are No Migrations

Calling Database.Migrate() or MigrateAsync() at startup in a project that has no migrations yet used to log a message and return. EF Core 10:

info: RelationalEventId.MigrationsNotFound[20406] (Microsoft.EntityFrameworkCore.Migrations)
      No migrations were found in assembly 'EfProbe'. A migration needs to be added before the database can be updated.
   MigrateAsync returned normally

EF Core 11 turns that into an exception:

InvalidOperationException: An error was generated for warning 'Microsoft.EntityFrameworkCore.Migrations.MigrationsNotFound': No migrations were found in assembly 'EfProbe'. A migration needs to be added before the database can be updated. This exception can be suppressed or logged by passing event ID 'RelationalEventId.MigrationsNotFound' to the 'ConfigureWarnings' method in 'DbContext.OnConfiguring' or 'AddDbContext'.

Usually it means one of two things: the migrations live in another assembly and MigrationsAssembly(...) is missing or wrong, or the app really has no migrations and should call EnsureCreated() instead. If neither applies (for example a shared startup path that runs for databases with and without migrations), ignore the event:

var options = new DbContextOptionsBuilder<ShopDb>()
    .UseSqlite("Data Source=migrate-test.db")
    .ConfigureWarnings(w => w.Ignore(RelationalEventId.MigrationsNotFound))
    .Options;

== Same call with ConfigureWarnings(w => w.Ignore(RelationalEventId.MigrationsNotFound))
   MigrateAsync returned normally

RelationalEventId is in Microsoft.EntityFrameworkCore.Diagnostics.

4. dotnet ef: Startup Project Doesn’t Reference Microsoft.EntityFrameworkCore.Design

Many projects only reference Microsoft.EntityFrameworkCore.Tools, because up to EF Core 10 it brought Microsoft.EntityFrameworkCore.Design with it. My test project:

<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="$(ExtVersion)" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="$(ExtVersion)" />

With 10.0.13, dotnet ef migrations add Initial works:

Build started...
Build succeeded.
Done. To undo this action, use 'ef migrations remove'

With 11 RC2 (and the matching dotnet-ef 11.0.0-rc.2.26504.105 tool), the build succeeds and the command stops:

Build started...
Build succeeded.
Your startup project 'ToolsOnly' doesn't reference Microsoft.EntityFrameworkCore.Design. This package is required for the Entity Framework Core Tools to work. Ensure your startup project is correct, install the package, and try again.

Add Design to the startup project directly. PrivateAssets="all" keeps it out of anything that references your project:

<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="$(ExtVersion)" PrivateAssets="all" />

After that the migration is created again. The same error appears when the startup project is the wrong one, so in a multi-project solution check --startup-project before adding packages.

5. Owned JSON Collections: OwnedEntityMappedToJsonCollectionWarning

Mapping a collection of owned types to a JSON column with OwnsMany(..., b => b.ToJson()) still works, but EF Core 11 now logs a warning when the owned type has no key:

modelBuilder.Entity<Blog>().OwnsMany(b => b.Posts, b => b.ToJson());

warn: RelationalEventId.OwnedEntityMappedToJsonCollectionWarning[20613] (Microsoft.EntityFrameworkCore.Model.Validation)
      The entity type 'Post' is an owned entity type mapped to JSON as a collection, which uses a synthesized ordinal key. Mapping owned entity collections to JSON is obsolete; map it as a complex type collection or configure a non-shadow key instead. See https://aka.ms/efcore-docs-json-owned-entities for more information.

EF Core 10 builds the same model without a warning. The recommended mapping is a complex collection, which I tested on both versions with a save and reload:

modelBuilder.Entity<Blog>().ComplexCollection(b => b.Posts, b => b.ToJson());

== ComplexCollection(b => b.Posts, b => b.ToJson()) (SQLite)
   model built, round trip: 1 post(s), first title 'EF Core 11'

Switching changes the model, so add a migration and look at what it generates before you apply it. If you need to keep OwnsMany for now, you can silence the warning. One gotcha: Microsoft’s breaking-changes page names it CoreEventId.OwnedEntityMappedToJsonCollectionWarning, but in the 11 RC2 packages it only exists on RelationalEventId (checked in the package XML docs):

.ConfigureWarnings(w => w.Ignore(RelationalEventId.OwnedEntityMappedToJsonCollectionWarning))

== OwnsMany + ConfigureWarnings(w => w.Ignore(RelationalEventId.OwnedEntityMappedToJsonCollectionWarning))
   model built

6. Microsoft.Data.Sqlite 11 Drops .NET Framework (NU1202 on net48)

EF Core itself left .NET Framework long ago, but plenty of WinForms and WPF apps on .NET Framework 4.8 use Microsoft.Data.Sqlite on its own. Version 10.0.13 still restores for net48. Version 11 does not:

error NU1202: Package Microsoft.Data.Sqlite 11.0.0-rc.2.26504.105 is not compatible with net48 (.NETFramework,Version=v4.8). Package Microsoft.Data.Sqlite 11.0.0-rc.2.26504.105 supports: net10.0 (.NETCoreApp,Version=v10.0)

There is no workaround inside the package: keep .NET Framework projects on Microsoft.Data.Sqlite 10.0.x (add it to your update tool’s ignore list) or move the project to modern .NET.

Also Check: SqlClient 7 and Entra ID Logins

EF Core 11’s SQL Server provider pulls in Microsoft.Data.SqlClient 7 (7.1.0 in my restore), which moved the Entra ID (Azure AD) authentication providers into a separate package. If your connection string has Authentication=Active Directory Default or another Active Directory mode, add Microsoft.Data.SqlClient.Extensions.Azure. The .NET 11 upgrade post shows the test: no provider registered without the package, provider registered with it.

What I Didn’t Test

The official list has more, and I’d rather say what I didn’t run than guess: the Cosmos DB provider changes (unmapped properties, sync I/O, id escaping), the SQL Server 2025 vector type, and the split-query concurrency exception, which needs a real race to reproduce. Read those in Breaking changes in EF Core 11 if you use them.

Upgrade Checklist

• Move the project to net11.0 before updating any EF Core package.
• Find out which SQL Server versions you deploy to; below 2022, add UseCompatibilityLevel(...).
• Search for Migrate()/MigrateAsync() and make sure each project that calls it has migrations or a correct MigrationsAssembly.
• Add Microsoft.EntityFrameworkCore.Design to every startup project you run dotnet ef against, and update the dotnet-ef tool to 11.
• Run the app once with warnings visible and look for event 20613; plan the move to ComplexCollection.
• Keep Microsoft.Data.Sqlite at 10.0.x in .NET Framework projects.
• If you use Entra ID logins, add Microsoft.Data.SqlClient.Extensions.Azure.

Related: Upgrading to .NET 11: 9 breaking changes · C# 15 union types · Repository pattern in C# · all ASP.NET Core tutorials