Entity Framework migrations stopped detecting the POCO updates

35
votes

I'm using Entity Framework and Entity Framework migrations to implement solution using code-first and automatic migrations.

It used to work great but suddenly it stopped detecting the updates I make to my POCO. Now when I add a new property (very simple properties like age or email) and execute the Update-Database, nothing happens, and it gives me this:

Specify the '-Verbose' flag to view SQL commands being executed during migration.
Found 0 pending explicit migrations: [].
Adding seed data (if Seed method overridden in Migrations Settings class).

and nothing gets updated!

Has anyone any idea why this is happening?

1
entity-frameworkmigrationef-code-firstentity-framework-migrations
Is the AutomaticMigrationsEnabled flag still set? – Betty
Yeah i've had some issues where I've had to reinstall it too, I wondered if it was because I was using the new NuGet 1.6 method of not storing packages in source control. – Betty
but here is how i fixed it with a workaround I uninstalled the Migration Package and installed it again, then update-database , it fixed it – Stacker
@Betty what i said is a workaround not a solution, i would rather not approve this as an answer, i have the latest patch of NuGet and i still get this issue from time to time. – Stacker
I've been having the same problem but with model-first. Modified my model and nothing was updated to the database... now that is mentioned, I am the only one in my team with NuGet... will get back to you – sebagomez

1 Answers

2
votes

This may be in two reasons:

  1. There is some other DbContext in code, that's why automatic migrations could not decide, which context to use.
  2. There is some new change, which loops a comparison of schema and code model, so EF simply could not find the difference.

In general, automatic migrations are simple and fast to implement, but it is not secured to use them. On some stage, such migrations could make a fail.

Several years ago, I have developed tiny ORM based on Linq2SQL, AcroDB Library, and it was using automigrations of SubSonic. Almost same as EF migrations can do now. It was perfect on small projects and small amount of data to process or change, but when project has grow into 15+ tables, it became a nightmare. That's why MS has announced Code-driven migrations lately. They are more secured and better for the project. Also, you can take a look to Migrator.Net (it is a bit better than EF, by this time).