Skip to content

Settings.EnumsFileName

Simon Hughes edited this page Oct 25, 2026 · 2 revisions

Writes every generated enum to one file instead of one file per enum, when you are generating separate files.

Type string
Default "" - one file per enum
Applies to EF 6 and EF Core
Databases All
In Database.tt? Yes, inside if (Settings.GenerateSeparateFiles)

What it does

Empty or null leaves enums as they have always been: each in its own file, named after the enum.

Set it to a file name and every enum goes into that one file instead, under a single header, using block and namespace. The file goes in Settings.PocoFolder, where the per-enum files would have gone.

if (Settings.GenerateSeparateFiles)
{
    // ... the folder settings ...
    Settings.EnumsFileName = "Enums"; // GenerateSeparateFiles only. If set, every enum is written to this one file instead of one file per enum, e.g. "Enums"
}

"Enums" and "Enums.cs" both produce Enums.cs.

Example

The examples assume two enum tables, OrderStatus and ShippingMethod - see Settings.Enumerations for how a table becomes an enum.

Settings.EnumsFileName = "" (default)

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

Settings.EnumsFileName = "Enums"

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

Enums.cs holds both:

// <auto-generated>

namespace MyApp.Data
{
    public enum OrderStatus
    {
        Pending = 1,
        Shipped = 2,
        Delivered = 3,
    }

    public enum ShippingMethod
    {
        Standard = 1,
        Express = 2,
    }

}
// </auto-generated>

When to use it

When the enums travel as a set. One file is easier to copy into another project - a DTO library shipped to the callers of your API, say - or to hand to a post-processing step than a dozen files mixed in with the entities.

When you have many small enums. Twenty lookup tables make twenty files of a few lines each; one file is quicker to read and to review.

Leave it empty if you want one type per file, which is the usual .NET convention and what most analysers expect.

Gotchas

It does nothing unless Settings.GenerateSeparateFiles is true. With separate files off, every class, enums included, is already in one file.

Pick a name no other generated file uses. The generator does not check for clashes. When two outputs have the same path, the one written later replaces the other, with no warning. The context, interface, factory and fakes are written first, then the entity classes, the configuration classes, the enums file, and last the owned entity classes and stored procedure return models. So:

  • Name it after an entity class - "Product" - and the enums file replaces Product.cs.
  • Name it after an owned entity class - "Address" - and that class replaces the enums file.
  • If Settings.PocoFolder is the same folder as the context, interface or configuration folder (for example, all of them empty), those files can clash too: "MyDbContext" or "FakeDbSet" would.
  • Case does not matter on Windows: "product" and "Product.cs" both hit Product.cs.

Usually the build then fails, naming the missing type. If nothing refers to the lost class, nothing tells you at all. To check, look in the *Audit.txt file next to your .tt: a clashing path is listed twice (compare ignoring case). "Enums" is safe unless you have an entity or owned entity class called Enums.

Switching either way cleans up after itself. The generator's audit file records what it wrote and deletes what it no longer writes, so turning this on removes the old per-enum files on the next run, and turning it off removes the combined file. Do not delete the *Audit.txt file, or the old files are left behind and you get "type already defined" errors.

No enums, no file. If the template generates no enums, the file is not written at all.

See also

Clone this wiki locally