Settings.AddIDbContextFactory

Settings.AddIDbContextFactory

Generates a factory class alongside the context, so design-time tooling and code that creates contexts on demand have something to call.

Type	bool
Default	true
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

Adds a MyDbContextFactory implementing IDesignTimeDbContextFactory<MyDbContext>.

Example

Settings.AddIDbContextFactory = true (default)

public interface IMyDbContext : IDisposable
public class MyDbContext : DbContext, IMyDbContext
public class MyDbContextFactory : IDesignTimeDbContextFactory<MyDbContext>
public class Category
public class Product
public class sales_Order
public class CategoryConfiguration : IEntityTypeConfiguration<Category>
public class ProductConfiguration : IEntityTypeConfiguration<Product>
public class sales_OrderConfiguration : IEntityTypeConfiguration<sales_Order>

Settings.AddIDbContextFactory = false

public interface IMyDbContext : IDisposable
public class MyDbContext : DbContext, IMyDbContext
public class Category
public class Product
public class sales_Order
public class CategoryConfiguration : IEntityTypeConfiguration<Category>
public class ProductConfiguration : IEntityTypeConfiguration<Product>
public class sales_OrderConfiguration : IEntityTypeConfiguration<sales_Order>

What the factory is for

dotnet ef needs one. The EF Core command-line tools have to construct your context outside your application's dependency injection container - to add a migration, to scaffold, to update the database. They look for an IDesignTimeDbContextFactory<T> implementation, and this is it. Without one, dotnet ef falls back to guessing, which works if your context has a parameterless constructor and fails confusingly otherwise.

Creating contexts per unit of work. A background service processing a queue wants a short-lived context per message, not one injected for the lifetime of the service. Injecting the factory and calling it per message is the supported pattern.

When to turn it off

You never run dotnet ef and you always inject the context. In a straightforward web application where the context is registered with AddDbContext and injected into controllers, nothing calls the factory and it is one class doing nothing.

You have your own factory. Two implementations of IDesignTimeDbContextFactory<T> for the same context make dotnet ef ambiguous, and it refuses rather than picking one.

You use AddDbContextFactory<T>. EF Core's own pooled factory registration provides IDbContextFactory<T>, which is a different interface from the design-time one, but the two are easy to confuse and having both invites it.

Gotchas

With OnConfiguration.Omit, the generated factory has no connection string. The factory calls the parameterless constructor, which with Omit configures nothing, so dotnet ef fails at the point it tries to connect. Either use a different Settings.OnConfiguration mode, or write your own factory that reads configuration and turn this off.

IDesignTimeDbContextFactory<T> is not IDbContextFactory<T>. The first is EF Core's design-time hook, in Microsoft.EntityFrameworkCore.Design. The second is the runtime factory you get from AddDbContextFactory. The generated class implements the first.

The factory is named after the context, so it follows Settings.DbContextName.

See also

• Settings.OnConfiguration - what the factory-created context is configured with
• Settings.DbContextName
• Migrations - where dotnet ef comes in
• Settings Reference