This project is read-only.


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


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 -

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

namespace Test.Forms
public class Question
  public Guid Id { get; set; }
Closed Dec 5, 2016 at 11:30 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub ( As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base ( Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
• It was a bug report that does not contain sufficient information for us to be able to reproduce it 
• It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it 
• It is a feature request that we are realistically not going to implement on the EF6.x code base
Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider ( We will no longer be monitoring this issue tracker for comments, so please do not reply here.


aszora wrote Sep 12, 2012 at 10: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 2: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 7: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 6: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 1: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 11:58 PM

This now works for EF6 but only when using Code First See:

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

RoMiller wrote Mar 8, 2013 at 7: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 8: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 5: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 4: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, 2014 at 1: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, 2014 at 3: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, 2014 at 2: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, 2014 at 2: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, 2014 at 9: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, 2014 at 7: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, 2014 at 11: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.

jplonghi wrote Mar 13, 2015 at 5:21 AM

Any update on this?

HansTsai wrote Apr 2, 2015 at 3:32 AM

Hello, Is any update for this issue??

It bothered me for a long time.

dellycowboy wrote May 12, 2015 at 6:03 PM

Honestly, I find this gobsmacking that the team feel that this is given so little priority, really not acceptable. That's all I have to say.

scaredoftheclaw wrote Jul 22, 2015 at 5:55 AM

I just came across this one. Thanks a lot Microsoft.

IoanHancu wrote Jul 28, 2015 at 7:12 PM

it was mentionned here :
that the team was aware and looking into it for EF6.

I'm running EF 6.1 and still running into this issue.
It has been reported on Sep 4, 2012 and still absolutely nothing to fix it, not even a temporary fix that does not involve horrible conventions for naming our tables.

This should really have a much higher priority than it has been getting... it's ridiculous...

Cupcake wrote Aug 9, 2015 at 8:48 PM

ooo this is soo bad! just can believe it. And no priority is seemed to be given to it. Wow just wow!

Cupcake wrote Aug 9, 2015 at 8:51 PM

I need to maintain the table names and not change them. what then do I do?

clyjr wrote Aug 10, 2015 at 2:05 PM

I can't believe this bug has been unfixed for so long. I'm working on a conversion project where 6-10 databases being converted are going to have the same table names. I have been using database first without issues until I just now ran into the first database that has duplicate table names. This should really have a higher priority and get fixed, it's pretty sad that a bug of this magnitude can go unfixed for 4-5 years...

aL3891 wrote Aug 12, 2015 at 11:19 AM

Very sad to see this issue being ignored. between CF and EF7 not supporting generating stored procs and this issue you're really putting your users in a tough spot.

You recommend using EF 6 and claim that it will be supported even after EF7 but those words ring pretty hollow when seeing something like this.

mihaikanyaro wrote Aug 25, 2015 at 1:47 PM

I have a project with 3 modules, which share class names, mapped under different SQL schemas. All went fine and dandy (except the fact that you can enable migrations on a single context) with the Code First implementation, until I've hit the aforementioned problem. Thanks Microsoft, next time I'll think twice before choosing EF against NHibernate.

delmontyb wrote Jan 15, 2016 at 9:12 PM

Does anyone have a good idea for a work around? I'm trying to think about how I want to move forward, as I have two databases for this application. Hum...

Really hoping we'll see this resolved soon.

divega wrote Feb 4, 2016 at 9:41 PM

In case it helps, in one of the most recent minor releases of EF6.x we added annotations that can be put in entity types in the EDMX to identify the CLR type they will be mapped at runtime deterministically, which avoids scanning assemblies for all possible candidate CLR types and avoids the exception.

The EDMX needs to be edited manually to add the annotations since the tools won't add them. For a simple model with a Person entity, the ConceptualModels section of the EDMX would look like this:
    <Schema Namespace="ConsoleApplication33" 
    <EntityType Name="Person" 
        customannotation:ClrType="MyApp.Person, MyApp, Version=, Culture=neutral, PublicKeyToken=null">
        <PropertyRef Name="Id" />
        <Property Name="Id" Type="Int32" Nullable="false" annotation:StoreGeneratedPattern="Identity" />
        <Property Name="Name" Type="String" MaxLength="Max" FixedLength="false" Unicode="true" />
    <EntityContainer Name="Town" customannotation:UseClrTypes="true">
        <EntitySet Name="People" EntityType="Self.Person" />
Notice in particular the customannotation:ClrType on the Person entity type and the customannotation:UseClrTypes on the entity container.