Settings.Runtime Values

Settings runtime values and helpers

The members of Settings that you read rather than set, plus the helper methods the generated code and your own callbacks can call.

Everything on this page is set by the generator, not by you. Assigning to them is either ignored or actively harmful. They are documented because the shipped Database.tt uses several of them in its examples, and because Settings.Root in particular turns up in five other wiki pages with no explanation anywhere.

Runtime values

Settings.Root

Type: string

The full path of the folder containing your .tt file. Set by the generator before your settings code runs, so it is safe to read anywhere in Database.tt.

This is the one you will actually use. Two common cases:

// A SQLite database sitting beside the .tt file
Settings.ConnectionString = "Data Source=" + Path.Combine(Settings.Root, "Northwind.db");

// File-based templates in a Templates sub-folder
Settings.TemplateFolder = Path.Combine(Settings.Root, "Templates");

The second is what the shipped Database.tt assigns by default. It matters for SQLite especially: a relative Data Source resolves against the process working directory, which is not your project folder, and SQLite silently creates an empty database rather than failing. See SQLite.

Settings.TemplateFile

Type: string

The name of the .tt file being run. Used internally to name the generated output file and to work out the default namespace. Reading it is harmless; setting it does nothing useful.

Settings.FilterCount

Type: int

How many DbContext filters the run produced - 1 for a normal single-context run, and one per context when Settings.GenerateSingleDbContext is false. Assigned by the file management service as generation starts, so it is only meaningful after that point.

Settings.DefaultConstructorArgument

Type: string Default: "Name={ConnectionStringName}"

EF 6 only. What the generated parameterless DbContext constructor passes to its base constructor. It derives from Settings.ConnectionStringName unless you assign it explicitly.

Set it to null to generate a constructor that does not call the base constructor at all, which is what you want when a base class of your own supplies the connection:

Settings.DefaultConstructorArgument = null;

Has no effect on EF Core, which uses Settings.OnConfiguration instead.

Settings.DefaultSchema

Type: string

The schema treated as the default and therefore never prepended to a class name. The database reader assigns it, so you normally read it rather than set it - which the shipped Database.tt does throughout its EnumDefinition and AddRelationship examples. See Settings.DefaultSchema for the per-database values.

Version helpers

Use these in a callback when a rule should only apply to some EF versions. They read Settings.TemplateType, so they are accurate as soon as it is set.

Helper	Returns true when
Settings.IsEf6()	TemplateType is Ef6 or FileBasedEf6
Settings.IsEfCore8Plus()	EF Core 8 or later
Settings.IsEfCore9Plus()	EF Core 9 or later
Settings.IsEfCore10Plus()	EF Core 10 or later
Settings.EfCoreVersion()	The major version as an int, or 0 for EF 6

Settings.ColumnIdentity = c => Settings.IsEfCore8Plus()
    ? ".UseIdentityColumn()"
    : ".UseSqlServerIdentityColumn()";

Partial-class helpers

These answer "did the user ask for partial?", by checking whether the relevant *Modifiers setting contains the word. The templates use them to decide whether to emit the partial void hooks.

Helper	Reads
Settings.DbContextClassIsPartial()	Settings.DbContextClassModifiers
Settings.EntityClassesArePartial()	Settings.EntityClassesModifiers
Settings.ConfigurationClassesArePartial()	Settings.ConfigurationClassesModifiers

DbContextClassIsPartial() is the one worth knowing: if it returns false, no OnModelCreatingPartial hook is generated, which is why Global Query Filters start by telling you to set Settings.DbContextClassModifiers = "public partial".

Provider helpers

Derived from Settings.DatabaseType, and used by the templates to write the right provider call and the right parameter syntax.

Helper	Returns
Settings.DatabaseProvider()	The UseXxx provider name, e.g. UseSqlServer
Settings.DatabaseProviderAssemblyName()	The provider assembly, e.g. Microsoft.Data.SqlClient
Settings.SqlParameter()	The parameter type, e.g. SqlParameter
Settings.SqlParameterValue()	How a parameter's value is read back for out parameters
Settings.NeedsNullForgiving()	true when AllowNullStrings or NullableReverseNavigationProperties is on, so the templates know to emit = null!

You are unlikely to need these unless you are writing a file-based template.

The UpdateColumn helpers

Not runtime values, but they belong with the rest of the "call, do not set" members. These are what make several other settings work, and the shipped Database.tt calls all four at the end of Settings.UpdateColumn:

Helper	Makes this setting work
Settings.ApplyDataAnnotations(column)	Settings.UseDataAnnotations
Settings.ApplyEnumTypeReplacement(column, table, enumDefinitions)	Settings.AddEnumDefinitions
Settings.ApplyJsonColumnMappings(column, table, jsonColumnMappings)	Settings.AddJsonColumnMappings
Settings.ApplyJsonPropertyNameAttribute(column)	The JsonPropertyName extended property

Settings.ApplyOwnedEntityMappings(table, ownedEntityMappings) is the table-level equivalent, called from Settings.UpdateTable.

If you replace UpdateColumn and drop these calls, those settings silently stop working. Nothing errors; the attributes and type replacements simply never appear. Add your own rules above the helpers, not instead of them.

See also

• Settings.UpdateColumn - where the Apply* helpers are called from
• Settings.OnConfiguration - the EF Core replacement for DefaultConstructorArgument
• SQLite - why Settings.Root matters more there than anywhere else
• Settings Reference