I have a project built in visual studio 2013 environment with the Db built using EF 5 code first. I have had my APIs working fine for a long time but all of a sudden I started to get this error that says:
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.
when I try to reach the end points of my APIs. I tried adding a new migration and then updating the database but still got the error. I then drop my entire database and recreated with EF. The end points of my APIs started working fine but then again I started getting this error on the web page. I have automatic migration set to true in the configuration file. I really have no idea why this is happening over and over. It's getting me really frustrated. Here's the full stack trace of the error:
[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.]
System.Data.Entity.Migrations.DbMigrator.Upgrade(IEnumerable`1 pendingMigrations, String targetMigrationId, String lastMigrationId) +579 System.Data.Entity.Migrations.DbMigrator.UpdateInternal(String targetMigration) +445
System.Data.Entity.Migrations.<>c__DisplayClassc.b__b() +13
System.Data.Entity.Migrations.DbMigrator.EnsureDatabaseExists(Action mustSucceedToKeepDatabase) +422
System.Data.Entity.Migrations.DbMigrator.Update(String targetMigration) +78
System.Data.Entity.Migrations.Infrastructure.MigratorBase.Update() +12 YourTimeSite.Global.ApplyDatabaseMigrations() in c:\Users\Ahmed\Desktop\YourTimeSite\YourTimeSite\Global.asax.cs:55
YourTimeSite.Global.Application_Start(Object sender, EventArgs e) in c:\Users\Ahmed\Desktop\YourTimeSite\YourTimeSite\Global.asax.cs:32[HttpException (0x80004005): 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.]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +9966013
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +118
System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +172
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +352
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +296[HttpException (0x80004005): 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.]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9947380 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +101
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.