The Mapping of Clr Type to Edm Type Is Ambiguous with Ef 6 & 5

The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM

I solved it by myself

by deleting the schema of duplicate tables

in the other context

The mapping of CLR type to EDM type is ambiguous because multiple CLR types

Yes, it is a known bug in Entity Framework 6 and below.
You could not use the same databases even though they are on different namespaces. This is happening in code first design as well and a post was opened on GitHub regarding the issue as well.

One of the developers even answered it stating:

This is already supported in the EF7 code base. We didn't really do
anything to explicitly support it, it was just a side effect of the
lighterweight purpose built metadata system in EF7 smile.

Meaning, that if you use Entity Framework 6 or below there is not much for you to do except not using the same Database twice in your code.

The mapping of CLR type to EDM type is ambiguous with only one EF model

I think this exception was actually caused by an issue in a LINQ to Entities query I modified in the BLL. I overlooked this change initially, but once I got the "offending" BLL class names changed, I was confronted with this exception:

Unable to cast the type
'System.Collections.Generic.IEnumerable1[[OrgName.ProjName.bllTableB,
ProjNameBLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]'
to type
'System.Collections.Generic.List
1[[OrgName.ProjName.bllTableB,
ProjNameBLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]'.
LINQ to Entities only supports casting EDM primitive or enumeration
types.

This runtime exception was thrown when I called .ToList() from GetTableAByID(Int32) in the following example:

Public Class TableA

Public Property TableAID as Integer
Public Property TableBs as New List(Of TableB)()
Public ReadOnly Property Amount as Decimal
Get
If Me.TableBs.Count > 0 Then
Return Me.TableBs.Sum(Function(tb) tb.Amount)
Else
Return 0
End If
End Get
End Property

Public Shared Function GetTableAs() As IQueryable(Of TableA)
Dim db As New DataAccess.ProjNameEntities()
Return (
From ta In db.TableAs
Order By ta.PaidDate Descending
Select New TableA With {
.TableAID = ta.TableAID,
.TableBs = (
From tb In db.TableBs
Where tb.TableAID = ta.TableAID
Select New TableB With {
.Amount = tb.Amount
}
)
}
)
End Function

Public Shared Function GetTableAByID(TableAID as Integer) as List(Of TableA)
Return (
From ta in GetTableAs()
Where ta.TableAID = TableAID
).ToList()
End Function
End Class

Public Class TableB
Public Property TableBID as Integer
Public Property TableAID as Integer
Public Property Amount as Decimal
End Class

Obviously there should be no problem converting from DbQuery<T> to List<T>, so I suspected the exception messages were just taking me on a wild goose chase. I decided to look at the query to see if something in there was causing the problem. Sure enough, that's where it was.

The offending section of this code seems to be where I select a New TableB into the List(Of TableB). I refactored the class & query to avoid this pattern (all I really needed was the Sum of TableB.Amount) and all errors cleared up.

I would love if any light could be shed on this issue and the VERY MISLEADING exceptions that resulted.

Edit:
I have increased the facepalm factor by discovering that just adding .ToList() to the end of the sub-query also fixes the issue:

.TableBs = (
From tb In db.TableBs
Where tb.TableAID = ta.TableAID
Select New TableB With {
.Amount = tb.Amount
}
).ToList()

The mapping of CLR type to EDM type is ambiguous with EF 4 classes ARE in a separate assembly

I had a problem like this once that had me baffled for a while. I used data first and copied the wrong connection string. it forced EF to resolve using the wrong model. I basically started over with the connection string, and presto.

Make sure your data first connection string lists the model properties correctly.

EF4.3.1 on .NET 4 - The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type

I think I got to the bottom of it today.

It looks to me that the enum type lives in a separate assembly and the cast triggers loading types from this assembly. This assembly happens to contain the type 'DTO.A' which matches the 'Entities.A' type. This cause the ambiguity which in turn causes an exception to be thrown. Note that did not happen in .NET Framework 4 since enum types in EF4 were not supported and cast operation did not cause loading types from the other assembly so for projects targeting .NET Framework 4 this is a regression in .NET Framework 4.5.
In EF6 the behavior will be the same regardless of .NET Framework version - we will always throw.



Related Topics



Leave a reply



Submit