Scaffold-dbcontext: Cannot combine -UseDataBaseNames with pluralizing

[kirodge]

My DB tables use camel case, where some table names starts with a capitalized acronym (i.e. XYTableName)

scaffold-dbcontext by default generates a DBSet property named XytableName (i. e. the acronym is not capitalized)

I can work around acronym capitalization by adding the "-UseDataBaseNames" switch to scaffold-dbcontext.
This results in a DBSet property named XYTableName (as expected)

But I also want my DBSet properties pluralized.
For this I use "Bricelam.EntityFrameworkCore.Pluralizer" (1.0.0-rc3).

Without -UseDataBaseNames, property names are pluralized as expected (XytableNames)
But with the -UseDatabaseNames switch no pluralizing is performed (XYTableName).

How can I get pluralized DBSet property names AND at the same time keep acronyms from the table name capitalized?

Further technical details

Microsoft.EntityFrameworkCore.Tools (2.1.0-rc1-final)
Database Provider: Microsoft.EntityFrameworkCore.SqlServer (2.0.3)
IDE: Visual Studio 2017 15.7.2

[ErikEJ]

+1 - EF Core Power Tools is also affected by this

[smitpatel]

Duplicate of #12007

[smitpatel]

As a work-around, overriding some service will give what is expected.
Currently UseDatabaseNames ignores all naming pipeline and just make sure that the name is valid C# identifier.

[bricelam]

This isn't a duplicate of #12007. The casing differences are irrelevant.

[ajcvickers]

Triage: Even if UseDatabaseNames is used, navigation properties should still be pluralized if the pluzalizer has been configured. DbSet names are more questionable.

[TjeuKayim]

I also experienced this issue. My database has a table named VCenterServers. I want the C#-class name to be VCenterServer (singular). But Scaffold-dbcontext outputs VcenterServer (with small c instead of capital).

I used a workaround to override CandidateNamingService.GenerateCandidateIdentifier(). https://gist.github.com/TjeuKayim/ed8d28652b5936a2d289c3ff7ebf0e08.

[ganySA]

Is there a solution to this.

Would it not be prudent to implement the same logic as in EF6 with DB first. I would assume that 99% of use cases would follow that approach.

The challenge here is we can get one thing or the other. Either we have the 'exact' DB names and no pluralization which will also break apps or we have some 'new' approach to converting which follows different logic to what happened in EF 6 DB first.

Is there a solution to this one?

[joshvote]

We've got a mountain of tables that could benefit from this. It's one of the major pain points for our .NET 4.6 -> .NET Core 3 migration. I'd be happy to contribute a PR if someone would be able to point me in the right direction of where to start.

[LordBenjamin]

Currently planning LINQ-to-SQL to EF Core migration. The difference in generated names is looking like one of the big pain points.

Looking to maintain existing SqlMetal.exe behaviour to minimize code changes - i.e.

• Pluralise table names
• Pluralise navigation properties
• Do not modify property (column) casing (unless not valid C# of course)

We cannot yet port the entire system to .NET Core in one go. We can't use the latest EF Core (3+) as this requires netstandard2.1, which isn't compatible with .NET 4.7.2.

Is the above possible to do with EF Core 2.2.6? If not, will it be possible to backport a solution or is EF Core 3 too different in this area?

EF Core 2 vs 3 might not be an issue if #18141 is landing soon?

EDIT: I've just updated to 3.1.0 using netstandard2.0.

EDIT 2: The custom CandidateNamingService posted by @TjeuKayim got me most of the way there. I also modifed the Pluralizer slightly to account for how SqlMetal.exe handled the word "data" (i.e. "data" is singluar and pluralises to "datas")

[paulovila]

Hi @ajcvickers @bricelam,
is there any progress on this one?
Regards.

[ajcvickers]

@paulovila As the milestone indicates, fixing this issue is currently in the plan for 5.0.