Virtual property and collection named badly when field name ends in f.ex. GUID

[TimesliceTechnologies]

Using Reverse Engineer to migrate from EF6 .Net Framework with EDMX and all its good stuff to EF6 Core.
I have some very large databases that have primary key fields and FK field names that end in "GUID". EG: UserGUID, OrderGUID etc. When Power Tools runs the reverse engineer it applies unexpected names to the virtual properties.

Example tables:
Users and UserLogins

• Primary key in Users is UserGUID
• Primary key in UserLogins is UserLoginGUID
• UserLogins relates to Users on UserLogins.UserGUID=Users.UserGUID

The generated UserLogin class includes virtual property for User named as UserGU
EG: public virtual User UserGU { get; set; }

The same issue applies to unusal names for one to many where the collection will be name something like:
public virtual ICollection TrusteeOwnerUserGUs { get; set; }
Instead of something more like TrusteeOwners.

There is considerable difference between what EF6 Framework generates when using database first to generate the EDMX and classes.
That's a really tough migration issue in any large application. This is especially true with respect to the collections. Not clear to me what the EDMX logic is for the relation naming, but that did set a standard at least for our shop.

I am including a VS2022 solution that has both a EF6 core class library and an EF6 Framework class library along with a SQL database creation script in the hope you can investigate and ideally arrive at something that will duplicate the naming that EF6 Framework generates (even if that is a new option). The alternative is a huge hill to climb migrating to Core and combing through gigabytes of code to adjust names.

Example:

Steps to reproduce

Load the attached VS2022 solution. Refer to EFtools class library and EFframework library in the solution.
Review the 3 classes in each project: User, UserLogin, Trustee, paying attention to any virtual property and the naming differences.

• Adjust connection strings to match yoru SQL server.
• Reverse engineer in EFtools (already done in the example provided)
• Review generated classes in EFframework / Model1.edmx which was generated from database.

Clearly the stuff that ends in "GU" seems incorrect (or at least undesirable).
Aside from that, duplicationg the naming that EF6 Framework produces would be the most preferred outcome.

Further technical details

EF Core version in use: EF Core 6

EF Core Power Tools version: 2.5.832

Database engine: SQL Server 2014

Visual Studio version: Visual Studio 2022 17.0.1

EFtoolsDBcreate.zip
EFtoolsTestSolution.zip

Thanks for your time! Great tool. Hope we can get this tweaked out...
Scott

[ErikEJ]

There is no simple fix for this, maybe you can try the Use Database names option

[TimesliceTechnologies]

I tried the use database names option to no avail.
Is the naming / pluralization logic implemented in the EF Core Power tools code or within EF Core itself? I presume the former.

For the naming of the virtual properites, the problem "feels" like some code that looks for something in a foreign key / relation name / key that ends in "ID" and then just trims off the last 2 chars instead of 4 characters. I'm just not clear on how/why the logic is applying GU (or GUs) to virtual properties that are created.

I haven't studied how EF 6 (framework) generates names when creating the EDMX and classes from database but it seems to have it nailed down very well.

If there is any possiblity of adjusting the naming logic to match EF6 or at the very least resolving the "GU" problem it would be most helpful.

[ErikEJ]

The Id Thing is in EF Core, and I cannot properly override it.

Disable pluralization.

[TimesliceTechnologies]

Thanks for the additional details. Pluralization on or off makes no difference with respect to the ID problem.
I have tried all the various switches in your options including pluralization settings. Try it yourself in the solution I uploaded.

The ID problem (IE: virtual methods leave "GU" in names of virtual properties) is apparently an issue with EF Core if I undertand correctly that the "reverse engineer" feature is either partially or fully a feature in EF core.

I'm new to EF Core and this would seem to be a bug in my view.
I've been using EF6 Framework for many years. I really miss the EDMX support, visualization, and its really solid support for database first.

Is it appropriate for me to follow up somewhere with the folks that manage the EF Core project regarding the "GUID" name issue and virtual methods? If so maybe you can point to the correct place for raising that issue...

[ErikEJ]

You should report in the EF Core repo, this look like a potential duplicate: dotnet/efcore#14278

[ErikEJ]

This is the offending code: https://github.com/dotnet/efcore/blob/fe1f86d53f4cad4701bed947d38e7371e450666e/src/EFCore.Design/Scaffolding/Internal/CandidateNamingService.cs#L143

[ErikEJ]

Looks like GetDependentEndCandidateNavigationPropertyName need to be overridden in this case

[ErikEJ]

@TimesliceTechnologies What is your proposed fix, looks like I can implement something.

Is it: Leave the name alone, even if it ends with "id" (case insenstive)

Or is it: Leave the name alone unless it ends with "Id" (case sensitive)

[TimesliceTechnologies]

Sorry for the delayed reply.
Ideally the fix would be to use the name of the table that the foreign key references rather than trying to infer it from a foreign key / field name. Subsequently pluralize if it is one to many or not plurlize if is 1:1 or 1:0

In lieu of that, then strip off GUID the same as it strips of "id" or "ID" or "Id" would be an improvement that in my example at least would be an improvement.

I realize this isn't your design and is part of the currently EF6 Core code that you rely on.
I'm not trying to be critical other than constructively of the reverse engineer built into EF6 Core.

Fundamentally, the reverse engineer should result in exactly the same model that EF6 Framework would create using EF6's "create from database" feature. Otherwise migration is a huge nightmare for anyone trying to migrate an application of any significant size from EF6 to EF6 Core. I have not examined the EF6 core code you referenced in any depth, but there seems to be an erroneous assumption that simply stripping 2 characters (ID, id, Id etc) off a field name used in a foreign key will resolve to a correctly named entity (IE: table name) that is identical to what EF6 framework generates (and quite well in my view).

The EF6 Core team really needs to exactly replicate the EF6 Framework logic (IE: Create model from database). Presumably the EF6 Framework code for this is available somewhere and transplanting it into EF6 Core should be feasible. Reverse engineer isn't an area that has an impact on performance - its basically design time only.

I value your insight and thoughts. It is entirely possibly I misunderstand the mechanism in EF6 Core's reverse engineer. Regardless, the end result should match EF6 Framework.

[ErikEJ]

I suggest you raise an issue in the EF Core repository, I have not been able to fidn a duplicate.

I do not plan to implement anything to fix this, as any fix will break existing code, and will be hard to get right.

You can use the bulk renaming feature to strip of of the weird "GUID" ending.

[TimesliceTechnologies]

Agreed and understood. This is primarily and issue in EFcore's functionality.
I suppose there is another alternative and that is to crawl the DB and build the model directly instead of relying on EFcore to do the reverse engineer. Thanks for your review of the issue.

[ErikEJ]

That does not sound like a viable alternative, I would look into using to global rename feature to replace words ending on GUID with GUIDID.

[ErikEJ]

This has been fixed in EF Core 7