3

I was having issues with a model not syncing with what Entity Framework thought was the current version so I wiped out all the migrations and started over as per this post.

After the reset. I went to enable Entity Framework and it gave this error.

More than one context type was found in the assembly 'Proj'. To enable migrations for Proj.Models.UsersContext, use Enable-Migrations -ContextTypeName Proj.Models.UsersContext. To enable migrations for Proj.Models.InjuriesContext, use Enable-Migrations -ContextTypeName PamperWeb.Models.InjuriesContext. ...for all my contexts

I was able to enable the first context, Users, but then when I tried to enable another I get an error saying

Migrations have already been enabled in project 'Proj'. To overwrite the existing migrations configuration, use the -Force parameter.

Apparently I am way off in how MVC and Entity Framework work. I have contexts set up in each of my model classes. Should I just have one Context and all my DBsets in that context? If so does it matter which model class file this one context goes with? All my current context's point to the same database.

Community
  • 1
  • 1
Xaxum
  • 3,545
  • 9
  • 46
  • 66
  • Why do you have multiple context classes? I haven't seen that done before. – Kirsten Jan 10 '13 at 04:57
  • 2
    @kristen g I thought each model class had to have a context. Didn't realize they should only be one context. – Xaxum Jan 10 '13 at 18:37
  • Thanks for posting this -- I made the same assumption when I saw the model provided in the basic MVC app, it has the classes "UserProfile" and "UsersContext" (which loads UserProfiles) -- I just figured each entity type was supposed to get its own context and that's how it's supposed to be. I was pulling my hair out over this! – BrainSlugs83 Jun 17 '13 at 07:40

1 Answers1

4

In normal application you should have single context with db sets for all your model classes. The context class should be in its own file. The context forms your whole model and gives you access to the database. It provides a lot of out-of-the-box functionality but the functionality is offered only for model classes registered in your context. If you divide model classes into separate contexts you lose some of the out-of-the-box functionality when working with entities loaded from different contexts.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670