Settings.ElementsToGenerate

Settings.ElementsToGenerate

Chooses which kinds of class the generator produces, so you can split the output across several projects.

Type	Elements - a [Flags] enum, so values combine with |
Default	Elements.Poco | Elements.Context | Elements.Interface | Elements.PocoConfiguration | Elements.Enum (everything)
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

By default one .tt file produces the whole data layer: the entity classes, the DbContext, its interface, the Fluent API configuration classes, and any enums.

That is what you want in a single project. It is not what you want when your solution separates concerns - a MyApp.Entities project that other projects reference, and a MyApp.Data project that owns the database. Putting one .tt in each and setting ElementsToGenerate differently gives each project only the classes that belong to it.

The five values:

Value	Generates
Elements.Poco	The entity classes - Product, Category, and so on
Elements.Context	The DbContext, plus IDbContextFactory if Settings.AddIDbContextFactory is on
Elements.Interface	The IMyDbContext interface
Elements.PocoConfiguration	The IEntityTypeConfiguration<T> classes that map entities to tables
Elements.Enum	Enums built from table data - see Enum Generation from Table Data

Elements.None generates nothing, which is occasionally useful while you are experimenting.

Example

All examples use the same three-table schema; only the type declarations are shown, since this setting is about which types appear rather than what is inside them.

Everything (the 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>

Elements.Poco - entity classes only

For a project that other projects reference and that must not depend on EF.

public class Category
public class Product
public class sales_Order

Elements.Context | Elements.Interface - the context, without the entities

For the data project, when the entities live somewhere else. Note that MyDbContextFactory comes along with Elements.Context.

public interface IMyDbContext : IDisposable
public class MyDbContext : DbContext, IMyDbContext
public class MyDbContextFactory : IDesignTimeDbContextFactory<MyDbContext>

Elements.Poco | Elements.PocoConfiguration

Entities and their table mappings, with no DbContext.

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>

When to use it

Splitting entities from the data layer. The common case. Two .tt files:

// 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";   // so the generated code adds the using

Settings.PocoNamespace is the part people forget. It does not move any files - it adds the using the DbContext needs to see entity classes that were generated into a different namespace.

Dropping the interface. Elements.Interface exists for mocking and dependency injection. If you inject MyDbContext directly, or use a repository layer, leave it out and generate one class fewer.

Gotchas

Both .tt files must see the same database. They are two independent runs. If one is regenerated against a newer schema than the other, the entity classes and the configuration classes stop agreeing, and you get compiler errors that point at the generated code rather than at the real cause. Regenerate both together.

Elements.Enum needs Elements.Poco for Settings.AddEnum to work. The AddEnum callback turns a table into an enum instead of an entity, so it needs both flags present to have something to convert and somewhere to put the result.

Leaving out Elements.PocoConfiguration does not make EF work by convention. Nothing maps the entities to tables any more, so you must either supply the configuration yourself or generate it in the other project.

This does not control file layout. Which files the output is split across is Settings.GenerateSeparateFiles and the folder settings. ElementsToGenerate only controls which classes exist at all.

See also

• Settings.PocoNamespace and the other namespace settings
• Settings.GenerateSeparateFiles
• Settings.AddIDbContextFactory
• Enum Generation from Table Data
• Settings Reference