0

I was studying this tutorial asp.net Movie Tutorial and I have 2 simple files in my model. 

 public class Movie { public int ID { get; set; } [Required] public string Title { get; set; } } public class MovieDBContext : DbContext { public DbSet<Movie> Movies { get; set; } }

And the other one is the Account Model that Visual Studio gives me :

 public class UsersContext : DbContext { public UsersContext() : base("DefaultConnection") { } public DbSet<UserProfile> UserProfiles { get; set; } } [Table("UserProfile")] public class UserProfile { [Key] [DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)] public int UserId { get; set; } public string UserName { get; set; } }

The problem is.... If I add a propety 

 public int aaa { get; set; }

to the UserProfile class, I get no changes in the migration....This happens because the migration only updates class that are inside the MovieDBContext.... So I must add something like:

public class MovieDBContext : DbContext { public DbSet<Movie> Movies { get; set; } public DbSet<UserProfile> User{get;set} }

The problem is that in another project I am trying to update the AccountModel and tried this solution but it didnt work.... Does anyone know another solution?

Improve this question
1
  • you said in the comment below that your login functionality breaks when you put them all in one DbContext class. What about the login breaks? Commented Apr 3, 2013 at 18:10

4 Answers 4

Reset to default
3

I think what you're experience is a 'connection' problem. (please check this out for a walkthrough I made earlier - and the connections link)
Migration does not alter my table (for connection issue)
Code first create tables

Put it into a single DbContext - you don't really need two (at least I think so). You just need to 'adjust' the connections when you do.

Specifically your UserContext has a connection specified (DefaultConnection). The other one (Movie...) does not - that means the other connection will be named MovieDbContext - and it tries to find it in your config file - if it doesn't succeed - it uses your default 'provider' to find the Db - and it creates a new Db there. While your UserContext probably already has a defined connection in the .config - and that one works.

Just move all to 'UserContext' - or adjust connections. see attached

Note:

Having multiple DbContext-s is what's called multi-tenant migrations - it's not supported as of yet (for EF5) - and is coming for EF6 Multiple Contexts per Database in EF6.

It simply cannot have 'two migration tables' in the same database - as each migration/context requires its own.

For a 'hack' you could force the Add-Migration to run - by doing something like Add-Migration -ConfigurationTypeName Test.Migrations.MovieConfiguration InitialMovie - and separately for the other one - but that won't work in a single project (it'd complain for migrations pending or something) - and if you move to two different - you'll hit 'one migration table' wall once you run the Update.

The other solution would be to turn off migrations (for one) but I haven't tried that - or run two context connecting to two databases - which you don't really want if you want to 'communicate' in between sort of. Either way - this is just for 'academic purposes' purely - it's not for your case.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

You should put all of your tables in a single DbContext class.

Everything will then work correctly.

Improve this answer

3 Comments

I cant do that.... If I change the place of public DbSet<UserProfile> UserProfiles { get; set; } ... the login functionality of my website stops working
I don't agree with this. It is better to separate everything according to its bounds, or what Julie Lehmann calls "Bounded Context". It provides also other performance benefits, etc.
Yeah, i agree with Husein, but is it possible to have "Bounded Context" with Model-First approach? Or is it only available for Code-First?
0

Entity Framework will only migrate one DbContext. Period. There's no way around this, currently. That means very plainly and simply that everything that EF will need to work with must be in this single context.

However, that doesn't preclude you from using other contexts elsewhere for different purposes. So in your MovieDBContext go ahead and add your UserProfile entity set:

public DbSet<UserProfile> User { get; set; }

Then, in your other contexts, you just need to 1) make sure they interact with the same database and 2) that they don't have an initialization strategy, e.g.:

public class AccountsContext : DbContext { public AccountsContext() : base("name=ConnectionStringNameHere") { Database.SetInitializer(null); } public DbSet<UserProfile> User { get; set; } ... }

That will make EF treat this context as a mapping to an existing database, so it won't try to create database tables, migrations, etc. All that will be done via your primary context (MovieDbContext in this case).

Improve this answer

Comments

0

you can use enable Migration like this :

Enable Migration -ContextTypeName UsersContext

or you can define public DbSet<UserProfile> User { get; set; } in your MovieDBContext like this :

public class MovieDBContext : DbContext { public DbSet<Movie> Movies { get; set; } public DbSet<UserProfile> User{get;set} }

and use this way :

Enable Migration -ContextTypeName MovieDBContext
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.