EntityFramework VS tools see model differently to runtime

Question

I am using EntityFramework 6.0.2 with explicit (not automatic) code-first migrations. My model is well established - I've been using this app for months and there have been many migrations added. The app uses MVC5.

After upgrading to MVC5.1, I'm now in a situation where the EF migration tools within VS see the model differently to the runtime. Running Add-Migration creates an empty migration, and Update-Migration thinks all outstanding migrations have been applied. However, when trying to start the site, it fails with AutomaticMigrationsDisabledException:

Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.

This appears to be related to elements in my model classes which have both [Required] and [AllowHtml] set on them. These are not new properties, but the first explicit migration I created after updating to MVC5.1 caused any properties with both of these attributes to be recreated without NOT NULL. This is when I began noticing the problem, as it's the point at which I could no longer run my app.

I do not want to remove the [AllowHtml] attribute. I'd like to find out why the Visual Studio tooling is seeing the model differently to the runtime. I have created a simple test project using MVC5.0, upgraded it to 5.1, and it did NOT show the same behaviour, so I'm looking for pointers on what to look for in my main project which could be affecting this.

There is another question with a similar problem, but not related to MVC5.1, suggesting this is probably to do with version differences somewhere. All of the many assemblies within my application are referencing the same version of all external dependencies such as MVC and EF.

I've reverted my code to MVC5.0 which made the problem go away for now, but the problem is still neither understood nor fixed (I still need to update to 5.1 at some point!).

Answer 1

It turns out that this problem was due to my project structure. I have multiple assemblies, but simplifying this it ends up being:

• Entities
• Data (DbContext & Configuration)
• Web App

These are NOT in the same solution, and are referenced from a central build output folder. The problem was that the Entities project had a reference to MVC (in order to use [AllowHtml]), but the data project didn't. When Visual Studio tooling ran in the data project to create a migration, it did not see MVC. However, because the migrations are run from the web project which DOES have MVC, this caused the different behaviour.

Answer 2

Entity Framework has a system table that it uses to track which migrations have been applied and a hash representation of your database state for each. The problem is that there's a mismatch here for some reason. It's a little hacky, but the easiest fix is actually to go ahead and apply that empty migration. EF will update the system table it uses with the current state and then it will think everything is fine again.

I've never run into this issue personally in production, but it's happened to me a few times in development, and, unfortunately, I've never been able to find a better fix, short of blowing out the database and let it recreate it. That's obviously not really an acceptable solution for something in production.