dotnet/efcore · error · OperationException

The wildcard '*' can only be used with commands that run…

Error message

The wildcard '*' can only be used with commands that run for all contexts found. Specify a context name for this command.

What it means

AddMigration rejects the literal context name '*' because adding a migration targets exactly one DbContext and must write files into one migrations assembly; the '*' wildcard (meaning 'all contexts') is only valid for commands that fan out across every context. The guard fires before any context is even created, so the throw is purely argument validation.

Solutions

Pass a concrete context name (or omit --context to let EF pick the only/Default) instead of '*'.
If you genuinely need migrations for several contexts, invoke AddMigration once per context name in a loop.

Example fix

// before
dotnet ef migrations add Initial --context *
// after
dotnet ef migrations add Initial --context MyDbContext

Defensive patterns

Strategy: validation

Validate before calling

// In a CLI wrapper, only pass '*' to verbs that accept it
static readonly HashSet<string> WildcardOk = new() { "database update", "migrations list", "migrations script" };
if (contextArg == "*" && !WildcardOk.Contains(verb))
{
    throw new ArgumentException("'--context *' is not valid for this verb. Specify a context name.");
}

Try / catch

try { operations.AddMigration(name, outputDir, contextType, ns, dryRun); }
catch (OperationException ex) when (ex.Message.Contains("wildcard '*' can only be used"))
{ /* re-run with an explicit context name */ }

Prevention

Treat '*' as opt-in per verb, not a generic flag.
Validate tooling inputs before forwarding to EF.
Document which EF verbs accept the wildcard.

When it happens

Trigger: Invoking MigrationsOperations.AddMigration with contextType == "*". This typically happens when a caller (a CLI wrapper, scripting tool, or test) passes the wildcard where a single context name is expected. The built-in dotnet ef / PMC commands never pass '*' to AddMigration.

Common situations: A custom tooling wrapper or PowerShell script that mechanically forwards a '--context *' flag to every EF command; misunderstanding which verbs accept the wildcard (Drop/Update/Script/List-Migration do; Add/Remove do not).

Related errors

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

Appendix: source

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

        _servicesBuilder = new DesignTimeServicesBuilder(assembly, startupAssembly, reporter, args);
    }

    /// <summary>
    ///     This is an internal API that supports the Entity Framework Core infrastructure and not subject to
    ///     the same compatibility standards as public APIs. It may be changed or removed without notice in
    ///     any release. You should only use it directly in your code with extreme caution and knowing that
    ///     doing so can result in application failures when updating to a new Entity Framework Core release.
    /// </summary>
    public virtual MigrationFiles AddMigration(
        string name,
        string? outputDir,
        string? contextType,
        string? @namespace,
        bool dryRun)
    {
        if (contextType == "*")
        {
            throw new OperationException(DesignStrings.WildcardNotSupported);
        }

        using var context = _contextOperations.CreateContext(contextType);
        var services = PrepareForMigration(name, context);

        using var scope = services.CreateScope();
        var (_, files) =
            CreateScaffoldedMigration(name, outputDir, @namespace, dryRun, scope.ServiceProvider);
        return files;
    }

    /// <summary>
    ///     Creates and saves a scaffolded migration using the provided services.
    /// </summary>
    public virtual (ScaffoldedMigration Migration, MigrationFiles Files)
        CreateScaffoldedMigration(
            string name,
            string? outputDir,

View on GitHub (pinned to 3a2006ef56)