Bug: Using T4 Context Splitting when the entity has "Configuration" at the end of the name, Incorrectly moves file.

[jwyza-pi]

Provide steps to reproduce a bug

1. Set the config to use use-t4-split.
2. Have an Table in your list of tables name, for example, "SoftwareConfiguration". (Any table that ends in Configuration will do though).
3. Run the scaffold.

Result:

The entity will end up getting put into a subfolder instead of the parent folder. Eg:

output-path = "Database/EFModels"

Expected is Database/EFModels/SoftwareConfiguration.cs, but instead is Database/EFModels/Configurations/SoftwareConfiguration.cs.

The actual IEntityTypeConfiguration file is correctly created under Database/Configurations/SoftwareConfigurationConfiguration.cs. It's just the model that is wrongly placed 1 level lower than it should have.

Edit: This is likely due to the code that moves all the Configuration files post-scaffold into the Configuration folder. The check I had written into it looks for files that EndsWith("Configuration.cs"), which obviously breaks down in this scenario.

Provide technical details

• EF Core Power Tools version: CLI 8.1.624

• Exact Visual Studio version: N/A

• Database engine: Azure SQL

• EF Core version in use: EF Core 8

• Is Handlebars templates used: no

• Is T4 templates used: yes (split)

• Is a SQL Server .dacpac used: no

[ErikEJ]

@jwyza-pi Interested in doing a bug fix?

[jwyza-pi]

Sure. My initial thought was to restrict which files are moved to only those that are in the same directory as the context. The only problem we'd run into is if you set the context and model directory to the same directory, then it'd end up having this same issue. so....maybe not that.

Another thought I had is to match up each entity file with each config file...... eg, for each file that ends with Configuration.cs, look for a file that has the same name without configuration.cs. If you find one, then this is a config file, if you don't, then it's not.

Or even the simplest of them is to say "check to see if there is a file named "ConfigurationConfiguration.cs". If there is, then this is an entity file and you shouldn't touch it.

or.... could open each file and inspect the contents. if it contains the IEntityTypeConfiguration type, then we know it's a config file and should be moved. That's likely the most iron clad, but also the slowest approach.

of the 4 possible options, it feels like # 2 is the most robust as long as we know there is always a 1:1 Entity->Config mapping, which I'm pretty sure there always should be.

[ErikEJ]

@jwyza-pi I think we have to go with # 4 as the user can choose any location for the entity files, and even generate these in a seperate run. Not so concerned with the perf impact, we are doing plenty of file IO anyway.

[jwyza-pi]

Submitted fix in #2726.

[jwyza-pi]

Morning! Do you have a timeline for when the next release that has this in it will go out? :)

[ErikEJ]

It is in the Nightly, and I am waiting for first patch Tuesday this year. So before end of this week there will be a new official release.