This folder contains code files for each schema modification that was made with Up() and Down() methods that add and remove a given migration. Your project that contains the DbContext for your EF application contains a Migrations folder. Note however, that if you remove the table and run your application it will run, as EF simply won't check if the schema matches. If this table exists EF checks to see whether the latest migration has been applied and if it hasn't fails and throws an error to the effect that the database and EF schema are out of sync. Go ahead and delete the _MigrationHistory table which tells EF what migrations have been applied. The first step is to remove the migrations table: The migrations got corrupted because the database is shared amongst multiple applications and the migration history was hopelessly bonked. I recently ran into this problem with a simple example database that I use for various applications. You've now essentially reset the schema to the latest version.Īgain if you had custom code in your old migrations that added custom constraints or modified data alongside of the generated Migration code you may have to add this code back in the initial migration generated. Update-database in PMC (does nothing but creates Migration Entry).Comment out the code inside of the Up method in the Initial Migration.Enable-Migrations in Package Manager Console.Remove the individual migration files in your project's Migrations folder.Remove the _MigrationHistory table from the Database.The idea of this process is basically this: The database and the EF schema are up to date and just the way you want it, so we are going to remove the existing migrations and create a new initial migration. But your mileage may vary, so whatever you do be safe about the data and code you already have and do the backup. You may have to add these additional manual steps to the initial migration that gets created…Īll that said I've had to do this sort of reset on a large project with a couple of hundred tables and it worked without a problem. This is especially true if you have custom code in your migrations that perform additional tasks to update the database. And you don't want to be stuck in that place without a backup. While the EF code generator is pretty good at matching the EF schema and what's in your database, in some cases it doesn't work. If you go the route of resetting your migrations, make sure you back up your code and make known good backups of your database, just in case the schema reversion doesn't do what you expect. There's no built-in way to do this, so you have to perform a number of manual steps and that's what this post is about. That might mean rolling back to the last known good migration.Īs you might expect, resetting migrations is not as obvious as it could be – it's not use case that Entity Framework expects you to work with. Usually this isn't a problem as databases tend to be vital in order for anything to work so they are very likely to be up date, but if not you'll have to find that consistent state so that your EF schema and the database are in sync. To be clear this works only if all of your databases are up to date in the first place or at least in some known consistent state. I've found in most cases it's simply easier to blow away the migrations and start with a clean slate from the current schema. There are a number of hacks you can try to fix bonked migrations, but to be honest more often than not those simply don't work. Usually this happens after a large number of migrations have been applied and I get stuck to where I can't update a database with new migrations or roll back. Not sure if this is a common occurrence, but I've had a number of occasions where Entity Framework migrations have left the state of migrations in an unusable state.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |