The mapping of CLR type to EDM type for exception tracking is ambiguous

Exception information:

"The specified schema is not valid. Error:
The mapping from CLR type to EDM type is ambiguous because multiple CLR types match EDM type 'person'.
The CLR type "a.person" was previously found,
The new found is CLR type "b.person". 

This kind of exception information appears in the code a few times, each time the solution is very surprising. Do not know why, and do not know why it was solved.

Check out some foreign information, links:

Don ' t use classes with the same NAME-EF uses only class names to identify the type mapped in EDMX (namespaces is ignore D)-It is a convention to allow mapping classes from different namespaces to the single model. The solution for your problem are to name your classes in BLL differently.

But the reality is that such anomalies do not always occur, but in an accidental situation. The so-called accidental situation, but is a very ordinary and simple call.

 
using (var con = new MyContainer())
{ string sql = "select top 1 name from cat"; var p = con.Database.SqlQuery<contract.Dog>(sql).FirstOrDefault();
    Console.WriteLine(p.Name);
}

Querying cat data, querying the first name data and storing it in contract. The Dog object. This kind of invocation is very common.

Organize your thoughts:

1. Thereis a "ambiguousmapping of CLR type to EDM type" exception, which must be the same class as the data structure in the EF model .

2. Classes with the same name as the EF data structure persist, but do not always error.

Do the following tests:

Test A

In the project where the EF data model is located (the following is represented by entity), the model person is established

At the same time, create a new class in the entity project, also named person (of course, the namespace is not the same), the same property (type and name).

debugging, you will find an error, error content ibid.

Test Two

On the basis of test one, remove the person class manually created in entity, create another project under the solution contract, create a new class in contract, name the person, and the attributes above.

Calling code:

 
using (var con = new MyContainer())
{ string sql = "select top 1 * from person"; var p = con.Database.SqlQuery<contract.Person>(sql).FirstOrDefault();
    Console.WriteLine(p.Name);
}

When you run this section alone, you will not get an error. Add the following paragraph:

 
using (var con = new MyContainer())
{
    string sql = "select top 1 * from person";
    var p = con.Database.SqlQuery<efentity.Person>(sql).FirstOrDefault();
    Console.WriteLine(p.Name);
}

After executing the above code, execute the following code immediately thereafter. An exception occurs, as in the exception.

Add breakpoints to track the data details of con.

Con.base._internalcontext.objectcontext.metadataworkspace._itemocspace.value (hereinafter referred to as Metaocspace) is empty until the first query is executed;

After the completion of the first paragraph of the query, the number of Metaocspace appears 32, specifically as follows:

The type mapping data for person appears, at which time the person type is mapped to Contract.person.

Omitting other test procedures, as a conclusion:

1. When a class of the same data model appears in entity, the same name is the same field, and whenever you use EF to manipulate the data, you will get an error.

2. When the assembly of the entity does not have the same name class, but other assembly (example contract) have the same name as the class. The query results are placed in any class object of entity, and then the query results are put into any class object of contract, the error will be indicated. The sequence of operations is reversed, the result is the same.

This is because DbContext's metadataworkspace once generated is cached. That is, in the same application domain, once the database has been manipulated with DbContext, it automatically reads all classes in the assembly of the class, attempts to match the database model, and then saves the matching results (saved to the metaocspace above). When the next operation of the database, the return data corresponding class class in the other assembly inside the class and the current matching database model conflict, will be error.

3. When the client refers to the entity + Client reference contract, there is a 2 risk. There is also a problem when entity references contract and then the client references entity.

This typically occurs when an enumeration type in EF is defined to refer to an external type (the type defined in contract), then an entity reference contract appears, and the client references the entity's scene. Match the following code:

 
using (var con = new MyContainer())
{ var p = con.Person.Where(pp => pp.Status == contract.We.One).FirstOrDefault();
    Console.WriteLine(p.Name);
}

At this time, there will be an error.

Solution Ideas:

1. Do not have the same field as the model in entity. Or in exchange for the model in entity plus special tags.

2. When EF operates a database, the data type of the returned data must be in the type defined in the entity project.

The above content, some details are not carefully examined, if there are other ideas please leave a message.

The mapping of CLR type to EDM type for exception tracking is ambiguous