Designer: Better navigation property names when multiple relationships to the same table


When multiple relationships to the same table are present the navigation properties are just postfixed with a name. We could consider using the FK name or some other means to make it clearer which is which.

This item was migrated from the DevDiv work item tracking system [ID=6053].

This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.


ceonur54 wrote Oct 20, 2012 at 10:28 AM

you can use nhibernate for .net for more clear naming.

but i want EF to become more powerful too.

RoMiller wrote Jan 24, 2013 at 10:29 PM

EF Team Triage: We are only taking minimal changes to the designer in EF6 because we are still converting the code base to open source. We'll consider this bug for the next release.

ata2931977 wrote Feb 24, 2013 at 11:30 AM

I always use a central Look-up table for my database, and this bug kills me, kindly please fix it a soon as you can, it will make the developer life much easier then when coding with navigation properties.

Trying to go around it by changing name in designer (a nightmare when you update it)
or add some extension properties that reference the navigation properties with incorrect naming. (extra code that is not needed and when updated the edmx sometimes it make problems too.)
or change in the T4 template to generate the navigation properties, but didn't master this yet.

KubuS wrote Dec 8, 2013 at 10:47 PM

Still a problem in EF 6.0.1

For example, I get 2 properties like:
[EdmRelationshipNavigationPropertyAttribute("Warehouse", "FK_DataOverride_DocumentType_After", "DataOverride")]
public EntityCollection<DataOverride> DataOverrides

[EdmRelationshipNavigationPropertyAttribute("Warehouse", "FK_DataOverride_DocumentType_Before", "DataOverride")]
public EntityCollection<DataOverride> DataOverrides1
where it could simply be:
[EdmRelationshipNavigationPropertyAttribute("Warehouse", "FK_DataOverride_DocumentType_After", "DataOverride")]
public EntityCollection<DataOverride> DataOverridesDocumentTypeAfter

[EdmRelationshipNavigationPropertyAttribute("Warehouse", "FK_DataOverride_DocumentType_Before", "DataOverride")]
public EntityCollection<DataOverride> DataOverridesDocumentTypeBefore
All the information is already in the foreign key name used by the designer.

mjw22 wrote Aug 29, 2014 at 10:11 PM

This is an amazingly painful bug for those of us that have to use existing databases that periodically change. Please provide us a way to customize the navigation naming property on the database side.

atomerz wrote Dec 2, 2014 at 9:14 AM

Annoying... How long do we have to wait to get this?

Arnop wrote Feb 5, 2015 at 10:50 AM

any progress on this?

IvanFerrer wrote Aug 19, 2015 at 3:43 PM

one possible workaround could be to parse the .edmx file using an external tool and replace all texts starting with
<NavigationProperty Name=
we have all needed information in one or two lines in the .edmx file (multiplicity, FK name, etc). Easy to parse.

huyhn0310 wrote Oct 27, 2015 at 2:51 AM

Any progress or workaround solution for this?
I tried change T4 template following http://stackoverflow.com/questions/12937193/improve-navigation-property-names-when-reverse-engineering-a-database but it got a error when connect database.

caioshin wrote Feb 11 at 1:26 PM

Hello guys! I'm also looking for a way to solve this problem!
It's really bad that the designer appends a number to the table name and use it as navigation property name instead of using its relation or associaton name!!
Replace strings in the code is absolutely dangerous, it would be good if there were some tool to do it even if after the generation process.

mbliesath wrote May 4 at 11:00 PM

I'm also having issues with this. Is there any update to this issue? Seems like the Code First from Existing Database is lacking if the navigation properties are generated like this with meaningless names.

Is it best practice to generate from an existing database the first time and then just modify the models moving forward? Then, you'd have to re-generate any newly created database objects from the models each time.

Or, is it still an ok practice to leave your models untouched and always generate from the database?