Tag: migrations

A shadow property is a column EF Core tracks without a matching CLR property. Here is why EF Core 11 creates them (missing FK properties, misnamed FKs, type mismatches, split relationships), how to spot the BlogId1 kind in a migration, how to fix each cause, and how to use shadow properties on purpose.

Map an EF Core key to an Oracle sequence with UseSequence in Oracle.EntityFrameworkCore 10: the DDL and INSERT SQL the provider really emits, how to point at an existing sequence or a legacy trigger, why quoting and HiLo trip people up, and how to move an identity column onto a sequence without ORA-00001.

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's Migrate() always checks whether the database exists and creates it if not, from a hardcoded master connection. Grant CREATE ANY DATABASE, fix the login's access to the existing database, or ship an idempotent SQL script instead.

Move a key off IDENTITY and onto a SQL Server sequence in EF Core 11 with UseSequence: the exact SQL EF emits, why explicit key values suddenly work without IDENTITY_INSERT, the bigint sequence feeding an int column, and the gaps you have to design around.

EF Core scaffolds RenameTable when you change the table name, but DropTable plus CreateTable when you rename the entity class. Here is how to tell the two apart, the ToTable trick that makes a class rename free, and the column-rename bug that silently swaps your data.

Add Microsoft.EntityFrameworkCore.Design to the startup project that dotnet ef builds, not the project holding your DbContext, and pass -s in layered solutions.

A complete guide to deploying EF Core 11 schema changes with migration bundles: building efbundle in CI, the appsettings.json trap with named connection strings, self-contained bundles and the Alpine musl RID, migration locking since EF Core 9, rolling back with a target migration, and why per-migration transactions do not save you on MySQL.

Migrations use the design-time DbContext, not your runtime CommandTimeout. Set the timeout via UseSqlServer(o => o.CommandTimeout(...)), the connection string Command Timeout, or Database.SetCommandTimeout before Migrate().

EF Core's design-time tools could not instantiate your DbContext. Either expose a host via WebApplication.CreateBuilder, point to the right startup project, or implement IDesignTimeDbContextFactory.