dotnet/efcore · error · OperationException

Your target project ' ' doesn't match your migrations…

Error message

Your target project '{assembly}' doesn't match your migrations assembly '{migrationsAssembly}'. Either change your target project or change your migrations assembly.
Change your migrations assembly by using DbContextOptionsBuilder. E.g. options.UseSqlServer(connection, b => b.MigrationsAssembly("{assembly}")). By default, the migrations assembly is the assembly containing the DbContext.
Change your target project to the migrations project by using the Package Manager Console's Default project drop-down list, or by executing "dotnet ef" from the directory containing the migrations project.

What it means

EnsureMigrationsAssembly checks that the assembly EF loaded the context from (_assembly, i.e. the target project) matches the configured MigrationsAssembly. If they differ (by simple name or full name), EF refuses to write migrations into an assembly other than the one you're running from, because the files would land in the wrong project and the snapshot would diverge. The error text is long and prescriptive because this is a very common configuration mistake.

Solutions

Run EF tooling from the project that the MigrationsAssembly is configured to: 'dotnet ef ... --project <DataLibrary> --startup-project <StartupApp>'.
Or change the MigrationsAssembly in OnConfiguring/UseSqlServer to match the project you run tooling from: options.UseSqlServer(conn, b => b.MigrationsAssembly(typeof(MyContext).Assembly.GetName().Name)).
Use the PMC 'Default project' drop-down to select the migrations project.
After renaming a project, update any literal MigrationsAssembly string.

Example fix

// before: tooling run from MyApp, but context says migrations live in MyApp.Data
options.UseSqlServer(conn, b => b.MigrationsAssembly("MyApp.Data"));
// fix option A: run from the data project
dotnet ef migrations add Init --project MyApp.Data --startup-project MyApp
// fix option B: align the assembly with the running project
options.UseSqlServer(conn, b => b.MigrationsAssembly("MyApp"));

Defensive patterns

Strategy: validation

Validate before calling

var ext = RelationalOptionsExtension.Extract(dbContextOptions);
var configured = ext?.MigrationsAssembly ?? context.GetType().Assembly.GetName().Name;
if (!string.Equals(configured, targetAssembly.GetName().Name, StringComparison.Ordinal)
    && !string.Equals(configured, targetAssembly.GetName().FullName, StringComparison.Ordinal))
{
    throw new InvalidOperationException($"Migrations assembly '{configured}' != target '{targetAssembly.GetName().Name}'.");
}

Try / catch

try { operations.AddMigration(...); }
catch (OperationException ex) when (ex.Message.Contains("doesn't match your migrations assembly"))
{ /* align --project with MigrationsAssembly or vice versa */ }

Prevention

Derive MigrationsAssembly from typeof(Context).Assembly rather than hardcoding a name.
Run EF tooling with explicit --project/--startup-project matching the layout.
Update MigrationsAssembly literals after project renames.

When it happens

Trigger: EnsureMigrationsAssembly runs on every migration-scaffolding operation. It throws when RelationalOptionsExtension.MigrationsAssemblyObject is either null or not equal to _assembly AND the resolved migrations assembly name does not match _assembly.GetName().Name (or FullName). Concretely: you ran 'dotnet ef migrations add' from project A but the context's UseSqlServer(... b => b.MigrationsAssembly("B")) points at project B.

Common situations: Solution layout: startup project != migrations project, and UseSqlServer's MigrationsAssembly points at the class library but you ran tooling from the startup app (or vice versa); copy-pasted options configuration carrying a hardcoded assembly name; renamed the data project without updating the MigrationsAssembly call.

Related errors

AI-assisted analysis of dotnet/efcore@3a2006ef56 (2026-08-11). Data as JSON: /api/errors/24796e5fc4f5e629. Report an issue: GitHub.

Appendix: source

Thrown at src/EFCore.Design/Design/Internal/MigrationsOperations.cs:491

    private void EnsureMigrationsAssembly(IServiceProvider services)
    {
        var assemblyName = _assembly.GetName();
        var options = services.GetRequiredService<IDbContextOptions>();
        var contextType = services.GetRequiredService<ICurrentDbContext>().Context.GetType();
        var optionsExtension = RelationalOptionsExtension.Extract(options);
        if (optionsExtension.MigrationsAssemblyObject == null
            || optionsExtension.MigrationsAssemblyObject != _assembly)
        {
            var migrationsAssemblyName = optionsExtension.MigrationsAssembly
                ?? optionsExtension.MigrationsAssemblyObject?.GetName().Name
                ?? contextType.Assembly.GetName().Name;
            if (assemblyName.Name != migrationsAssemblyName
                && assemblyName.FullName != migrationsAssemblyName)
            {
                throw new OperationException(
                    DesignStrings.MigrationsAssemblyMismatch(assemblyName.Name, migrationsAssemblyName));
            }
        }
    }
}

View on GitHub (pinned to 3a2006ef56)