EF Core 11

The existence check in your handler is not the guard you think it is. Put a unique index on the inbox table, write the marker in the same SaveChanges as the business change, and let the database pick the winner. Plus the ExecuteUpdate trap that quietly undoes all of it.

There is no transaction that spans SQL Server and Blob Storage. Upload to a name the database already knows about, commit second, compensate on failure, and let a sweeper clean up the crash window. With the UploadAsync overload that silently turns a conditional create into an overwrite.

Rename every PK_, FK_, AK_ and IX_ that EF Core 11 generates with one IModelFinalizingConvention, keep explicit names winning, stay under the identifier length limit, and avoid the clustered-index rebuild the next migration scaffolds on an existing database.

EF Core 11 stops escaping '/', '\', '?' and '#' in generated Cosmos DB id values, so documents written by EF Core 8-10 stop resolving by key. How to find out if you are affected, when to set the EscapeIllegalCosmosIdCharacters switch, and how to rewrite the ids safely with a transactional batch.

EF Core 11 now defaults UseSqlServer to compatibility level 160, which puts LEAST, GREATEST and two-argument LTRIM/RTRIM into your SQL, including every Take(n).FirstOrDefault(). Keep 160 on SQL Server 2022 and later; pin UseCompatibilityLevel(150) if any environment still runs SQL Server 2019.

EF Core's SQL Server existence check retries error 18456 for a full minute, with or without EnableRetryOnFailure. Fail fast, cap RetryTimeout, or wait for EF Core 12.

EF Core 11 is compiled against Microsoft.Data.SqlClient 7.0.0.0, but a 6.x copy won the restore or the deploy. Remove the old SqlClient pin and redeploy the full output.

StartsWith, EndsWith and Contains already escape % and _ for you in EF Core 11, but EF.Functions.Like does not. Here is the SQL EF generates, a reusable escape helper, and the escapeCharacter overload that makes it work on SQL Server, SQLite and PostgreSQL.

Use the native json type on SQL Server 2025 and Azure SQL: EF Core 11 gets JSON_CONTAINS, typed JSON_VALUE, in-place modify() and JSON indexes out of it. Stay on nvarchar(max) for SQL Server 2019/2022, legacy tooling, or a schema you must be able to roll back.

EF Core's build-time model generation re-entered MSBuild until RAM ran out. Upgrade Tasks and Design to 10.0.10+, and on EF Core 11 delete EFOptimizeContext.