EF context changed, but without updating database structure

2

I'm using the free hosting service in a free plan. Until then, everything worked fine.

But after I've made some changes to my database, their database just does not work, it gets error:

  

The model backing the 'ContextEntities' context has changed since the database was created. Consider using Code First Migrations to update the database

This has already happened to me on my local machine and I resolved using the command line: Update-Database -Verbose that forces the database to be updated. And with that all worked out right.

I've done this several times on my local machine before uploading it, I've updated the database, but still their bank service says my context has changed and I have not updated it (I already have) / p>

Ok, searching I found this response from SOen which gives the proposed solution to add the following line in Global.asax :

Database.SetInitializer<YourDbContext>(null);

My questions are: How does this work? Is there another way I can resolve this problem (since I do not have access to the database because I'm using a free plan)?

    
asked by anonymous 04.02.2015 / 01:39

1 answer

2

How does this work?

SetInitializer as null tells the Entity Framework that the base has no initialization class. By default, it is MigrateDatabaseToLatestVersion , which runs all pending Migrations from the last Migration detected to the most recent Migration .

Is there another way I can solve this problem (since I do not have access to the database because I'm using a free plan)?

You may not have EnableAutomaticMigrations configured in class Configuration within Migrations , or MigrateDatabaseToLatestVersion would have solved your problem.

There are three solutions:

1. Generate an additional Migration

It is the simplest solution, but the Migration created can come empty. It's rare, but it does.

2. Delete database and create another

This is more radical. It always works, but requires a backup of the database and a new deploy.

3. Delete all records from __MigrationHistory and do a manual update of the test database for production

This is the boldest solution, and should only be used if you are sure that the schema in production is identical to that of development. Indicated for those who do not want to have to knock down the base to go up another.

    
04.02.2015 / 03:04