views:

262

answers:

2

I am experiencing an issue with EF4 and Proxy Pocos.

I have 2 classes with the same name in the same assembly but different namespaces:

QuoteModels.CashPayment
OrderModels.CashPayment

This compiles fine but at runtime EF throws the following exception:

Schema specified is not valid. Errors: \r\nThe mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'CashPayment'. Previously found CLR type 'QuoteModels.CashPayment', newly found CLR type 'OrderModels.CashPayment'

Is there a workaround to have classes with the same name in the same assembly with different namespaces to work with Ef4?

Do I have to give them different names or move them into another assembly?

+1  A: 

Take a look at this post. The Derek's comment seems to deal with the same issue, and he did not receive any answer from Microsoft.

Devart
He did: @DerekThis is intentional. You can put your POCO classes in whatever namespace you'd like. The Entity Framework's by convention mechanism for detecting which properties on the entity match the properties of entities in your model does not use Namespace. What matters is that the type name (without namespace) matches the EntityType name in your model (edmx/csdl file).One area to watch out for is if you have multiple types with the same name but in different namespaces. Because we don't account for namespace, we detect that we've found multiple types and we throw an exception.Jeff
Jaxidian
Thanks for that clarification. Any idea why they did this by design? Is this going to change in the future? I'd like to have the ability to have POCOs in the same assembly but different namespaces have the same names, you know?
KenB
None whatsoever. I'm struggling with this right now and am needing to find a solution. My problem is that not ALL of my classes that match this cause the problem. It seems to only be caused by tables that act as many-to-many relationships. For example, in your scenario, if `CashPayment` is a standard table storing financial information, it works as expected for me! However, if `CashPayment` is simply a many-to-many table pointing to 0-to-many `CashTransaction` entities (hence making `CashPayment` a collection of type `CashTransaction`), then it blows up on the `CashPayment` table. Make sense?
Jaxidian
Correction: It sometimes works on non many-to-many tables and sometimes doesn't. I can't find a pattern but I definitely have it working in some scenarios - strange!
Jaxidian
+1  A: 

I've found a work-around. It's a very obvious work-around that is non-ideal, but I think I'm going to call it good enough for us until EF5 comes out to fix this.

In our scenario, we're using a DB-first approach (we're rewriting a legacy app with minimal DB changes). Our DB contains hundreds of tables, so rather than using a single EDMX/Context, I'm using multiple EDMX/Contexts (the EDMX has croaked every time I've attempted to add more than half of our tables). However, some tables need to exist in more than one EDMX/Context.

For discussion, let's pretend we have a simple database with the following tables:

  • Person
  • Family
  • Relationship
  • Address
  • Business
  • Employee

Also, for the sake of this discussion, let's assume that ANY table that exists in multiple contexts causes this problem (as I stated in comments to Devart's answer, this is not really true and I don't understand why it sometimes works).

Now let's say we want to create two contexts: PersonalContext:

  • Person
  • Family
  • Relationship
  • Address

WorkContext:

  • Person
  • Business
  • Address
  • Employee

In this scenario, both Person and Address will cause our problem. So what we will do in our EDMX mapping is simply rename our entities to Person_Personal/Person_Work and Address_Personal/Address_Work.

As stated, this is very much an obvious work-around that is non-ideal but since EF doesn't take namespacing into account and goes strictly by name (not true identity, simply the name), one obvious way is to put your namespacing in your name.

Now I'm still debating if I'm going to do it that way or perhaps namespace the name for every entity (Personal_Person, Personal_Family, Personal_Relationship, Personal_Address and Work_Person, Work_Business, Work_Address, and Work_Employee) for both consistency and Intellisense-friendliness (keeping all entities in proper alphabetic order) since really, the namespace belongs before the name instead of after it, but that's a judgement call and not really important to providing a solution to the problem.

I hope this helps!!

Jaxidian