dotnet/efcore · error · InvalidOperationException

A call was made to '{optionCall}' that changed an option tha

Error message

A call was made to '{optionCall}' that changed an option that must be constant within a service provider, but Entity Framework is not building its own internal service provider. Either allow Entity Framework to build the service provider by removing the call to '{useInternalServiceProvider}', or ensure that the configuration for '{optionCall}' does not change for all uses of a given service provider passed to '{useInternalServiceProvider}'.

What it means

Thrown by InMemorySingletonOptions.Validate when the configured IsNullabilityCheckEnabled value differs between DbContext instances sharing the same internal (singleton) service provider. EF Core caches singleton options per internal service provider, so any per-context variation in this option is rejected to prevent silent cross-context corruption.

Source

Thrown at src/EFCore.InMemory/Infrastructure/Internal/InMemorySingletonOptions.cs:43

        {
            IsNullabilityCheckEnabled = inMemoryOptions.IsNullabilityCheckEnabled;
        }
    }

    /// <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 void Validate(IDbContextOptions options)
    {
        var inMemoryOptions = options.FindExtension<InMemoryOptionsExtension>();

        if (inMemoryOptions != null
            && IsNullabilityCheckEnabled != inMemoryOptions.IsNullabilityCheckEnabled)
        {
            throw new InvalidOperationException(
                CoreStrings.SingletonOptionChanged(
                    nameof(InMemoryDbContextOptionsBuilder.EnableNullChecks),
                    nameof(DbContextOptionsBuilder.UseInternalServiceProvider)));
        }
    }

    /// <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 bool IsNullabilityCheckEnabled { get; private set; }
}

View on GitHub (pinned to 3a2006ef56)

Solutions

Make EnableNullChecks consistent across every DbContext that shares the internal service provider.
Remove UseInternalServiceProvider and let EF build (and cache) its own provider per options configuration.
Use distinct internal service providers for contexts that must differ in null-check behavior.
Set the option once at startup via a shared configuration helper so all contexts agree.

Example fix

// before - inconsistent across shared provider
optionsA.UseInternalServiceProvider(sp).UseInMemoryDatabase("A");
optionsB.UseInMemoryDatabase("B").EnableNullChecks();
// after - agree on the option
optionsA.UseInMemoryDatabase("A").EnableNullChecks();
optionsB.UseInMemoryDatabase("B").EnableNullChecks();

Defensive patterns

Strategy: validation

Validate before calling

// Ensure all contexts sharing the provider agree on EnableNullChecks
bool want = config.GetValue<bool>("InMemory:EnableNullChecks");
options.UseInMemoryDatabase("db");
if (want) ((InMemoryDbContextOptionsBuilder)options.Extensions...).EnableNullChecks();
// simpler: centralize options construction

Try / catch

try { dbContext.Database.EnsureCreated(); }
catch (InvalidOperationException ex) when (ex.Message.Contains("SingletonOptionChanged"))
{
    // reconcile the option across contexts or drop UseInternalServiceProvider
}

Prevention

Construct DbContext options once via a factory so every shared-provider context agrees.
Avoid UseInternalServiceProvider unless you pool contexts with identical options.
Store the nullability-check setting in a single config value read everywhere.

When it happens

Trigger: Using DbContextOptionsBuilder.UseInternalServiceProvider(sp) and configuring one context with EnableNullChecks (or the IsNullabilityCheckEnabled option) while another context on the same provider does not, then Validate is invoked.

Common situations: Pooling or manually sharing an internal service provider across contexts whose nullability-check preference differs. Toggling EnableNullChecks in tests while the production context already created the singleton options. Disposing/re-creating contexts against a shared provider with different settings.

Related errors

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