Settings.GenerateSeparateFiles

Settings.GenerateSeparateFiles

Writes one file per class instead of putting the whole data layer in a single Database.cs.

Type	bool
Default	false
Applies to	EF 6 and EF Core
Databases	All
In Database.tt?	Yes

What it does

false puts everything - the interface, the DbContext, every entity and every configuration class - into one .cs file nested under your .tt.

true writes each class to its own file in the same folder, and enables the four folder settings so you can organise them further.

Example

Settings.GenerateSeparateFiles = false (default)

Database.cs

One file, containing every class.

Settings.GenerateSeparateFiles = true

Category.cs
CategoryConfiguration.cs
IMyDbContext.cs
MyDbContext.cs
MyDbContextFactory.cs
Product.cs
ProductConfiguration.cs
sales_Order.cs
sales_OrderConfiguration.cs

With folders

The shipped Database.tt sets the folder settings inside if (Settings.GenerateSeparateFiles), because they have nothing to do until this is on:

if (Settings.GenerateSeparateFiles)
{
    Settings.ContextFolder           = @"Data";
    Settings.InterfaceFolder         = @"Data\Interface";
    Settings.PocoFolder              = @"Data\Entities";
    Settings.PocoConfigurationFolder = @"Data\Configuration";
}

Data/Configuration/CategoryConfiguration.cs
Data/Configuration/ProductConfiguration.cs
Data/Configuration/sales_OrderConfiguration.cs
Data/Entities/Category.cs
Data/Entities/Product.cs
Data/Entities/sales_Order.cs
Data/Interface/IMyDbContext.cs
Data/MyDbContext.cs
Data/MyDbContextFactory.cs

When to use it

Turn it on for anything beyond a small database. A single file containing sixty entities is thousands of lines, and:

• Diffs become unreadable. Adding a column touches one file that every other change also touches, so every regeneration conflicts with every other.
• Navigation is worse. "Go to definition" lands you in the middle of a huge file rather than in Product.cs.
• Merge conflicts are guaranteed as soon as two people regenerate on different branches.

Leave it off for a handful of tables, or when you want the whole model visible in one scroll.

Gotchas

Turning it on leaves the old file behind. Database.cs is not deleted, and it still contains a full copy of every class - so you get "type already defined" errors until you delete it by hand. This catches everyone once.

Turning it off leaves the separate files behind, with the same result in reverse.

An audit file records what was generated. The generator writes a *Audit.txt alongside the output listing the files it produced, and uses it on the next run to delete files it no longer generates. That is what stops a renamed table leaving its old class behind. Do not delete it, and do commit it.

Old-style projects need the files adding by hand. If your .csproj lists every file with <Compile Include="..." /> rather than globbing, newly generated files exist on disk but are not in the project. SDK-style projects pick them up automatically. See Settings.FileManagerType for why v4 no longer manipulates the project file.

The folder settings do nothing while this is off, because there is only one file and it goes next to the .tt.

See also

• Settings.PocoFolder and the other folder settings
• Settings.UseFolderNameInNamespace - matching the namespace to the folder
• Settings.ElementsToGenerate - splitting the output across projects rather than files
• Settings Reference