Settings.Namespace

Settings.Namespace and the other namespace settings

Which namespace the generated code lives in, how it is written, and how to point one project's generated code at another's.

Setting	Type	Default
`Settings.Namespace`	`string`	`DefaultNamespace`
`Settings.UseNamespace`	`bool`	`true`
`Settings.UseFileScopedNamespaces`	`bool`	`false`
`Settings.UseFolderNameInNamespace`	`bool`	`false`
`Settings.ContextNamespace`	`string`	`""`
`Settings.InterfaceNamespace`	`string`	`""`
`Settings.PocoNamespace`	`string`	`""`
`Settings.PocoConfigurationNamespace`	`string`	`""`

Settings.Namespace

The namespace everything generated goes into.

The default, DefaultNamespace, is a variable the T4 host supplies - it resolves to your project's root namespace. To override it, use a quoted string:

Settings.Namespace = "MyCompany.MyProject.Data";

If your generated namespace changed when you upgraded to v4, this is where to pin it. v4 asks the T4 host for the root namespace, where v3 went through the Visual Studio automation model, and the two can disagree.

Settings.UseNamespace

false suppresses the namespace declaration entirely, so the generated types land in the global namespace.

Rarely useful. It exists for single-file scripting scenarios and for templates that wrap the output in their own namespace. Turning it off also disables Settings.UseFileScopedNamespaces, because there is no declaration to change the style of.

Settings.UseFileScopedNamespaces

namespace MyApp.Data; instead of namespace MyApp.Data { ... }, removing a level of indentation from every generated file.

namespace MyApp.Data

becomes

namespace MyApp.Data;

Requires C# 10, which needs <LangVersion>10</LangVersion> or later - available on net48 too, as long as the project is SDK-style. Full detail on File-Scoped Namespaces.

The four cross-namespace settings

These do not move any files. They add using statements, so generated code in one namespace can see generated code in another.

You need them when you split generation across projects with Settings.ElementsToGenerate:

// MyApp.Entities\Entities.tt
Settings.ElementsToGenerate = Elements.Poco;
Settings.Namespace          = "MyApp.Entities";

// MyApp.Data\Data.tt
Settings.ElementsToGenerate = Elements.Context | Elements.Interface | Elements.PocoConfiguration;
Settings.Namespace          = "MyApp.Data";
Settings.PocoNamespace      = "MyApp.Entities";   // <-- the using the context needs

Without that last line the DbContext refers to Product and cannot find it.

Set the one that names where the other thing lives:

Setting	Says where to find
`Settings.PocoNamespace`	The entity classes
`Settings.ContextNamespace`	The `DbContext`
`Settings.InterfaceNamespace`	The context interface
`Settings.PocoConfigurationNamespace`	The configuration classes

Gotchas

DefaultNamespace is not a string, and not quoted. It is a T4 variable. Settings.Namespace = DefaultNamespace; is correct; Settings.Namespace = "DefaultNamespace"; puts your code in a namespace literally called that.

UseFolderNameInNamespace and the four cross-namespace settings are unrelated. The first makes the namespace follow the output folder; the others add using lines. Turning the first on changes what the others need to point at.

Both projects must be regenerated together. They are two independent runs against the same database, and if one is stale the entity classes and the configuration classes stop agreeing.

A namespace is usually better than Settings.TableSuffix for avoiding a clash with existing types - it costs one using rather than putting Dto in front of every reader forever.

Settings.Namespace

Settings.Namespace and the other namespace settings