Repository navigation
Settings.EnumsFileName
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)
|
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.
The examples assume two enum tables, OrderStatus and ShippingMethod - see
Settings.Enumerations for how a table becomes an enum.
Category.cs
CategoryConfiguration.cs
IMyDbContext.cs
MyDbContext.cs
MyDbContextFactory.cs
OrderStatus.cs
Product.cs
ProductConfiguration.cs
ShippingMethod.cs
sales_Order.cs
sales_OrderConfiguration.cs
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 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.
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 replacesProduct.cs. - Name it after an owned entity class -
"Address"- and that class replaces the enums file. - If
Settings.PocoFolderis 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 hitProduct.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.
- Settings.GenerateSeparateFiles - the switch that makes this do anything
- Settings.PocoFolder - the folder the file goes in
- Settings.Enumerations - turning lookup tables into enums
- Enum Generation from Table Data
- Settings Reference
- Home
- Compared with the Microsoft scaffolder
- Connection strings
- JetBrains Rider
- Upgrading from v3 to v4
- Saving .tt does nothing
- Settings A-Z - every setting, with a page each
- Common Settings Types Explained
- Settings Callbacks
- Settings runtime values and helpers
- Filtering
- Full Control Over the Generated Code
- Enum Generation from Table Data
- Owned Entities
- JSON column support
- Global Query Filters
- Extended Property Names Feature
- Partial Properties
- File-Scoped Namespaces
- Data Annotations
- Spatial Types
- HierarchyId
- RowVersion and TimeStamp columns
- Lazy Loading
- Stored proc result sets