92
Vote

Can't map two classes with same name from different namespace

description

EF doesn't allow two classes with the same name, but different namespaces, to be mapped.

This is complex to change so we also have an item to provide a better exception message until this is supported - http://entityframework.codeplex.com/workitem/589

namespace Test.Security
{
public class Question
{
  public Guid Id { get; set; }
}
}

namespace Test.Forms
{
public class Question
{
  public Guid Id { get; set; }
}
}

comments

aszora wrote Sep 12, 2012 at 9:36 AM

The problem with EF codefirst that it uses a flat namespace internally.

For examaple if you have a Question class which has an Answer navigation property the internal modelmetada will contain a reference called QUESTION_ANSWER.

So if occasionally you have a view in the database named QUESTION_ANSWER, you cant use it, because of duplicate name:)
(I did this when I tried to specify a view for many-to-many rel for example.)

mousedoc wrote Sep 12, 2012 at 1:51 PM

Yes, but that is a significant problem with EF. It will allow the following to compile for the above.

public class MyTextContext : DbContext
{
public DbSet<Test.Security.Question> Security_Question { get; set; }
public DbSet<Test.Forms.Question> Forms_Question { get; set; }
}

Took me a long time to track it down because the error message was something like "Question not mapped". When I would at the data annotations on classes and the fluent API it was clear I had things configured properly.

RoMiller wrote Oct 16, 2012 at 6:08 PM

Updating title and description to reflect that this is a general EF issue and not specific to Code First.

This is a limitation of EF that we plan to fix but it is complicated and not something we are planning to address in EF6. Marking to be fixed in a future release.

glide wrote Nov 21, 2012 at 5:05 PM

Just ran into this problem when trying to create entities that are separated by schema in the database and using custom T4 templates to generate the entities into different namespaces.

moozzyk wrote Jan 7, 2013 at 12:44 AM

Adding exception message to make it easier to find:

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'ABC'. Previously found CLR type 'Ns1.ABC', newly found CLR type 'Ns2.ABC."}

ajcvickers wrote Mar 1, 2013 at 10:58 PM

This now works for EF6 but only when using Code First See: http://entityframework.codeplex.com/workitem/911

This item remains open and in futures for Database First and Model First.

RoMiller wrote Mar 8, 2013 at 6:11 PM

To add to what Arthur said - we've fixed (for Code First only) the issue that prevented you having a Question class in your model and then another Question class that isn't in your model and lived in a different namespace. In EF6 we have not enabled having two Question classes included in your model.

mousedoc wrote Mar 8, 2013 at 7:03 PM

Both were in my model, so this doesn't help my situation. I could have just applied an Ignore attribute to the class if I wanted this fix.

guru_fordy wrote Oct 31, 2013 at 4:05 PM

Just ran into this for the first time on EF 6.01 using DB First. To say I was disappointed that it was only fixed in CF was an understatement. I am at the end of a SOA proof of concept and putting two service calls through to two separate EDM's with one shared table breaks the code. Both EDM's separated by assembly and namespace, but that obviously means nothing to EF.

Is there an ETA on a fix to this or should I be looking at other ORM's that can handle my situation?

sanilpaul wrote Nov 11, 2013 at 3:11 PM

Is there an ETA to fix this? Just as the previous comments, we are building software based on SOA. Each boundary has its on schema. Order in Sales have a different meaning as Order in Inventory. Now we are forced to pollute the code base due to EF restrictions by having a name different than the ubiquitous naming in each context. Very painful

Powdor wrote Feb 5 at 12:48 PM

We are providing data services based on EF where we need versioning. So new versions are put in seperate namespaces (not changing the class name). this caused the same issue. Now we need to pollute old versoins with a postfix to work arround the issue.

It would be great if it would simply take the namespace into account.

cragun wrote Feb 5 at 2:23 PM

I would like to up vote the priority of this fix as well. Needs to get fixed asap. Modern programming languages have namespaces and EF needs to respect this. As many have said, the only work around is seriously polluting your Models with less than ideal naming conventions.

tonyatl wrote May 26 at 1:43 PM

cragun's comments are exactly my own and far more restrained. that this defect is considered low impact is nonsense - it makes using ef like shopping for tourist novelties in a tacky airport gift shop.

UberError wrote Aug 13 at 1:13 PM

I agree with the above posts. This issue should take priority as it promotes bad naming conventions in SQL to accommodate an oversight in EF.

Godrules500 wrote Aug 22 at 8:33 PM

I agree. I have several applications, each which has its own schema, that I would like to import into the EF. Now I'm going to have to separate my EDMX files instead of having 1, or create an extremely ugly naming convention in the db.

Is there any update on this issue being fixed?

tboring wrote Oct 7 at 6:01 AM

I just ran into this issue for the first time--using EF 5. Funny thing is, this issue hasn't been happening until now, and my code's been in PROD for 6 months. We recently enhanced the database, adding 14 new tables. We then added the new entities and classes, and now two of the entities/tables that have the same name, but are in different DB schema and namespaces are, I presume, conflicting.

RichardPawson wrote Oct 7 at 10:59 AM

Rowan - please tell us if this issue is going to be fixed in EF 7. It is a major limitation if you are building large scale enterprise systems (as we are and many others in the above comments, clearly).

More generally, now that the code base & issues list has shifted to GitHub - is anyone paying attention to issues on CodePlex now. This one has 87 votes, but I can't find any equivalent on the GitHub issues list.