This may be in two reasons:
- There is some other DbContext in code, that’s why automatic migrations could not decide, which context to use.
- 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).