Settings.AddParameterlessConstructorToDbContext

Settings.AddParameterlessConstructorToDbContext and Settings.UseInheritedBaseInterfaceFunctions

Two small settings about what the generated DbContext and its interface declare for themselves.


	`Settings.AddParameterlessConstructorToDbContext`	`Settings.UseInheritedBaseInterfaceFunctions`
Type	`bool`	`bool`
Default	`true`	`false`
Applies to	EF 6 only	EF 6 and EF Core
In `Database.tt`?	Yes	Yes

Settings.AddParameterlessConstructorToDbContext

EF 6 only. Controls whether the generated context has a public MyDbContext() that passes the connection string name to its base:

public MyDbContext()
    : base("Name=MyDbContext")
{
}

The argument comes from Settings.DefaultConstructorArgument, which derives from Settings.ConnectionStringName unless you set it.

Turn it off when a base class of your own supplies the connection, or when you always construct the context with an explicit connection and want the compiler to enforce that.

The EF Core equivalent is Settings.OnConfiguration. On EF Core the parameterless constructor is always generated, and what it does is decided there.

Settings.UseInheritedBaseInterfaceFunctions

The generated IMyDbContext normally declares everything itself - SaveChanges, Add, Attach, Entry, Find, Remove, Update, Database, Set<T> and the async variants. That is a long list, and if you have your own base interface declaring some of them you now have them twice.

Turn this on and the interface declares only the DbSet properties and the stored procedure methods, taking everything else from whatever Settings.DbContextInterfaceBaseClasses names.

Settings.DbContextInterfaceBaseClasses      = "IDisposable, IMyDataContext";
Settings.UseInheritedBaseInterfaceFunctions = true;

Turn it on when you have a shared context interface across several generated contexts and want the common members declared once. Leave it off otherwise, which is the case for most people - the generated interface is then self-contained and needs nothing from you.

Gotchas

UseInheritedBaseInterfaceFunctions with the default IDisposable will not compile. IDisposable declares Dispose() and nothing else, so the generated context implements an interface that no longer requires SaveChanges while your code still calls it through the interface. Turn it on only alongside a base interface that actually declares the members.

The base interface must match EF's signatures exactly, generic constraints and CancellationToken defaults included. A near-miss produces a context that does not implement its own interface.

AddParameterlessConstructorToDbContext is ignored on EF Core. The setting is read and does nothing, which is easy to miss when porting a v3 .tt that relied on it.

Turning off the parameterless constructor breaks the generated factory. Settings.AddIDbContextFactory generates a factory that calls it. Turn both off together, or supply your own factory.

Settings.AddParameterlessConstructorToDbContext

Settings.AddParameterlessConstructorToDbContext and Settings.UseInheritedBaseInterfaceFunctions