Question

I'm quite new to Entity Framework, but the more I worked with it, the more I actually liked it. But now my passion is at risk, as I'm struggeling with an issue that already made me crush my head against the wall.

The problem is the following:

I'm using Entity Framework 5.0 with code-first approach plus inheritance for my business models represented by Table Per Hierarchy. At first I had all of my entity types, that were supposed to be mapped, in the same assembly as my DbContext (which worked fine for both TPH and TPT). But as they also contain logic that is dependent on other assemblies, this turned out as no good approach since it caused circular dependencies because those assemblies also need to have knowledge of the Data Access Layer, which in turn has to have knowledge of the entity types that it is supposed to map).

I solved this issue by introducing a CommonObjects project, where I now keep all of my abstract classes and stripped out the concrete descendents (containing the logic, etc.) of those base classes into the specific projects, which are responsible for them. (see: Circular Dependency Solution)

It compiled and everything seemed to fit the way I imagined it. But now it turned out that Entity Framework seems to struggle with the derivates being in a different assembly than the base classes.

During runtime, when trying to access the DbContext the first time, the compiler threw an InvalidOperationException saying:

The abstract type 'Foo.Bar.AbstractClass' has no mapped descendents and so cannot be mapped. Either remove 'Foo.Bar.AbstractClass' from the model or add one or more types deriving from 'Foo.Bar.AbstractClass' to the model.

So EF is obviously not able to find the descendents, as it only knows the base classes (which are in the CommonObjects project), but the descendents are in a different assembly.

DbSet<AbstractClass> AbstractClasses { get; set; }

According to this question: Entity Framework Code First and Multiple Assemblies I tried to add the following code to the constructor of my derived DbContext:

((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace.LoadFromAssembly(
            Assembly.Load("Foo1"));

But that did not work for me. While debugging and watching the MetadataWorkspace the method "LoadFromAssembly" did obviously not have any effect on the MetadataWorkspace and its items (no types were loaded from assembly Foo1).

What am I missing here?

Thanks for your answers in advance.

Ben

Was it helpful?

Solution

EDIT: This only barely works and isn't worth it, and doesn't work at all if you're using CodeFirst.

I have encountered the same issue with code first. I tried your method of reflection. This seems a bit wonky, but you can trick EF into being okay with your set up with an internal class.

    internal class ClassToMakeEFHappy : AbstractClass {}

I just created that in the same file as my AbstractClass definition and it did the trick.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top