Skip to content

Settings.ConnectionStringName

Simon Hughes edited this page Aug 30, 2026 · 1 revision

Settings.ConnectionString, Settings.ConnectionStringName and Settings.ConnectionStringActions

Three settings with similar names doing three different jobs. Getting them confused is the most common first-run problem.

Setting Used by When
Settings.ConnectionString The generator Design time, when you save Database.tt
Settings.ConnectionStringName Your application Run time, as a key in configuration
Settings.ConnectionStringActions Your application Run time, appended to the provider setup

Settings.ConnectionString

Type: string Default: a **TODO** placeholder Required: yes

The full, working connection string the generator uses to read your schema. It is passed to the efrpg tool over stdin when you save the .tt.

The generator never reads your appsettings.json. You have to hand it the whole string.

Settings.ConnectionString = "Data Source=(local);Initial Catalog=Northwind;Integrated Security=True;Encrypt=false;TrustServerCertificate=true";

Depending on Settings.OnConfiguration, this value may also be copied into the generated DbContext. If it contains a password and you would rather it did not end up in source control, use OnConfiguration.Omit or OnConfiguration.Configuration.

Settings.ConnectionStringName

Type: string Default: "MyDbContext"

Just a key. It is placed into the generated code so the context can look the real connection string up at run time, from appsettings.json on EF Core or app.config / web.config on EF 6.

Settings.ConnectionStringName = "Northwind";
{
  "ConnectionStrings": {
    "Northwind": "Data Source=(local);Initial Catalog=Northwind;Integrated Security=True"
  }
}

The generator never uses this value itself. It does not connect with it, and it does not validate that anything of that name exists.

Settings.ConnectionStringActions

Type: string Default: "" EF Core only

Extra fluent calls appended to the provider setup inside OnConfiguring:

Settings.ConnectionStringActions = ".EnableRetryOnFailure(maxRetryCount: 10, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null)";

which produces:

optionsBuilder.UseSqlServer(@"...", x => x
    .EnableRetryOnFailure(maxRetryCount: 10, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null));

Use it for connection resiliency, a command timeout, or a provider-specific option such as .UseNetTopologySuite().

Gotchas

Both name settings default to "MyDbContext", and so does Settings.DbContextName. Three settings, one default value, three different meanings. Renaming the context does not rename the connection string key.

ConnectionString is a design-time secret in a source file. Database.tt is committed, so anything you type into it is committed. Connection strings covers three ways round that - an environment variable, a file outside the repository, or reading your own appsettings.Development.json from the .tt.

ConnectionStringActions does nothing with OnConfiguration.Omit, because there is no generated provider call to append to. Configure the provider where you register the context instead.

ConnectionStringActions is written verbatim, starting with the dot. Forget the leading . and the generated code does not compile.

On EF 6, ConnectionStringName feeds the parameterless constructor through Settings.DefaultConstructorArgument, which passes "Name=<value>" to the base constructor. EF Core uses OnConfiguration instead.

To test a connection string without the template, run the tool by hand:

efrpg --database SqlServer --connection "Data Source=(local);Initial Catalog=Northwind;Integrated Security=True;Encrypt=false;TrustServerCertificate=true"

XML on stdout means the connection is fine and the problem is elsewhere.

See also

Clone this wiki locally