Entity Framework bug? "Context changed" Error, even when not

Question

I have gotten myself into an odd Groundhog Day scenario with an MVC application of mine.
Unless I apply my workaround (Later in this question) each time I debug the application I'm presented with this error:

The model backing the 'UsersContext' context has changed since the database was created. Consider using Code First Migrations to update the database (http://go.microsoft.com/fwlink/?LinkId=238269).

I have not changed the model.

My workaround workflow is:

1. Add-Migration WHATEVERNAME (Makes a blank migration)
2. Delete this migration.
3. Run: Update-Database
4. Recompile & Run (Now without error)

Notes:

• The __MigrationHistory hashes of the latest migration match in both script and in the database.
• I have my MVC application & EF project as separate projects.
• I have tried creating an -IgnoreChanges migration, to see if applying this would mitigate the issue. It did not.

This is quite frustrating, how would I solve this issue permanently?

Note: Automatic migrations are not suitable for my scenario.

Answer 1

This can happen when updating to EF6 which made schema changes to the _MigrationHistory table (https://msdn.microsoft.com/en-us/data/jj591621)

The EF6 version has a new column ContextKey so the migration is probably trying to add that column.

I'm guessing if you scaffold it will just be making those changes - or perhaps there's something you changed a long time ago that wasn't 'picked up' yet for some reason.

OR if you just don't want to deal with it right now you can disable migrations temporarily.

 System.Data.Entity.Database.SetInitializer<UsersContext>(null);

Answer 2

Well, it's almost impossible to understand what's wrong without knowing much more detail. So all I can do is give you some clues of what you could try.

1. Stopping and restarting the app should not cause the DB to get out of date. Is it only when debugging? Have you tried running the app without debugging? Then recycle the app pool and running the app again.

2. Do you have any weird post-build step that will overwrite some DLL in your "bin" folder?

3. Is your app doing something that changes the database schema, thereby invalidating it when you next start up? Run SQL profiler to check what is happening to the DB when your app starts up.

4. Migrate back to the first version of your schema, and then back again (backup your DB first):
   update-database -TargetMigration:0 -verbose

   then

   update-database -verbose

5. Temporarily comment out the bulk of your app to try to isolate the cause.

6. Create a brand new app with EF configured in the same way, copy the connection string and see if it happens for that. If not, then there must be something different. If yes, then show us your EF settings.

Hopefully something here that could give you an idea at least. Good luck!

Answer 3

Enabling migrations sets up the whole migration system. But to enable automatic migrations you have to include -EnableAutomaticMigrations which simply adds the line

AutomaticMigrationsEnabled = true; into the newly generated Configurations.cs file.

In conjunction with the database initializer, development turnaround is more streamlined because you no longer have to type add-migration and update-database every time you make a change. That will happen automatically now. However, that’s not enough, if you want column removals you have to also perform step 3, where automatic data loss is supported.

When you are ready to release software (internally or externally) where you need strict version control and to upgrade databases on site, you should remove automatic migrations and add a manual migration point.