Unable to update database to match the current model because there are pending changes

I had a lot of trouble with this but the answer for me was to exclude intermediate database migration items that altered tables which were already created with those alterations. If I knew a bit more about what I am doing here, I think I would follow the advice above on the DbContext settings.

Running update-database produced the same errors, but:

• adding an empty migration (via PM) and then update_database worked

add-migration EmptyMigration

Then run

update-database

At this point the migrations ran without error.

• To wit, several migrations required exclusion from the project (not understanding how the CodeFirst project had already created these migrations and thus they were unneeded and therefore, "exclude"-able).
• Project Migrations included intermediate steps that updated the table structure that EntityFramework had already applied (Entity Framework newbie- I am - working with CodeFirst examples from udemy - MVC5 course)
• What began as "Unable to create explicit migration for..." (VS2019)
• Then "No pending explicit migrations.Found invalid data while decoding."

• Followed instructions to delete obj folder and then clear the cache from Nuget without any result.

• Next, tried to delete and recreate the database with an empty database (I'm running developer version of SQL Server but Express would be the same) using SSMS. This part may or may not have been needed.

• Brought the project up and noticed it was Net Framework 4.5 so updated to 4.7. Again, not sure if it was needed. The sample project was built for Community Edition 2013.

• Restarted the project (VS2019)

• Performed two steps above and everything is working now.

There's not really enough here to diagnose the root cause of the issue, but generally, you will only get that error if you're database is out of sync with your entity classes in some way. If you truly believe it is not, you can disable this exception from occurring by deleting the _MigrationHistory table from your production database. At that point, EF will treat the database as existing, and no longer prompt you to migrate it. Instead, you'll get exceptions only when it find unexpected/missing columns, or other SQL errors resulting from schema desynchronization. In some ways, that's better though, as if there actually is something off, you'll have better idea of exactly what is off, rather than being broadly told that you need to migrate.

However, removing the migration history table means that you will then be responsible for keeping it synced up if you do make changes to your entity classes. Generally, that's not a problem, anyways. It's a poor idea to run migrations against a production database, anyways, so this actually forces you to explicitly update the schema when necessary, hopefully using proper change management policies.

If you are doing anything manual in your DbContext implementation, my situation may help you.

In my case, in my DbContext construction sequence, I was manually performing migration checks. In other words, I was utilizing Database.SetInitializer.

In a few short lines, I am initializing a context and messing with SetInitializer. As part of that, I am also playing with the Initialization Strategy MigrateDatabaseToLatestVersion<TContext, TMigrationsConfiguration>

Lastly, my generic types, which are generic implementations I developed, were different levels of abstraction. I tested amongst using typing between:

• DbMigrationsConfiguration, EF's basic DbContext Configuration
• BaseConfiguration, My abstract base DbContext Configuration
• <U>, allowing the user to pass in their implementation of my base.

In the end, it turns out the different SetInitializer calls and DbContext instantiations needed to all be using <U> or, probably, just the same level of abstraction of the same classes.

TLDR - Check if you're using SetInitializer with generics, and make sure your generics are all 100% exactly the same, not bases/subclasses of each other.