Could not find Entity Framework context for type

Jun 20, 2013 at 6:56 PM
Hi there.
I had code that has been working for a long time, using the type SmdCoreModel.Province.
We recently added a Province type in a different model also. Both model assemblies are referenced by the MVC project and there are connection strings for both in the web.config.
Now I'm getting this error:
Could not find Entity Framework context for type: SmdCoreModel.Province Possible causes: 1. Missing connection string in App.config 2. Mismatch between class properties and entity properties 3. Attempting to persist a non-persisted type
When I explicitly associate SmdCoreModel.Province with the context name with the following code in RunWeb, then it starts working again.
var p = new EntityPersistorInstaller();
p.UsingEdmxContext("ModelA").AssociateTypes(ModelATypes);
However, if I read the manual, section 2.3.6.7. "How to work with multiple database contexts", I understand that NOF should still be able to resolve the context without my explicit associations, all-be-it a bit slower.

Am I missing something?
Coordinator
Jun 22, 2013 at 10:17 AM
Edited Jun 22, 2013 at 10:18 AM
NOF should be capable of finding the context for any class without you having to use 'AssociateTasks', so I am surprised at this behaviour - but, obviously, I can't see everything that's going on in your system. In any event, I do recommend that you use AssociateTasks on any production system that uses multiple contexts, if only to improve performance.

Please advise the fully-qualified names of the two implementations of Province (i.e. with both namespaces) - so I can try a test.
Jun 22, 2013 at 10:29 AM
Edited Jun 22, 2013 at 11:05 PM
The below 2 are in different assemblies.
SmdCoreModel.Province
Smd.Appointments.Data.Province
Edit
PS, it is not a big deal. I have it functioning now. Just found it strange based on the docs and thought I would let you know.
Coordinator
Jun 24, 2013 at 10:12 PM
FYI I checked and we do have an automated test as part of the build that retrieves two types from two different contexts that have the same type name but different namespaces. So I assume there's something else complicating the situation in your particular case.