Reset Entity-Framework Migrations

You need to :

Delete the state: Delete the migrations folder in your project; And Delete the __MigrationHistory table in your database (may be under system tables); Then Run the following command in the Package Manager Console: Enable-Migrations -EnableAutomaticMigrations -Force Use with or without -EnableAutomaticMigrations And finally, you can run: Add-Migration Initial

The Issue: You have mucked up your migrations and you would like to reset it without deleting your existing tables.

The Problem: You can't reset migrations with existing tables in the database as EF wants to create the tables from scratch.

What to do:

Delete existing migrations from Migrations_History table. Delete existing migrations from the Migrations Folder. Run add-migration Reset. This will create a migration in your Migration folder that includes creating the tables (but it will not run it so it will not error out.) You now need to create the initial row in the MigrationHistory table so EF has a snapshot of the current state. EF will do this if you apply a migration. However, you can't apply the migration that you just made as the tables already exist in your database. So go into the Migration and comment out all the code inside the "Up" method. Now run update-database. It will apply the Migration (while not actually changing the database) and create a snapshot row in MigrationHistory.

You have now reset your migrations and may continue with normal migrations.

How about

Update-Database –TargetMigration: $InitialDatabase

in Package Manager Console? It should reset all updates to its very early state.

Reference link: Code First Migrations - Migrating to a Specific Version (Including Downgrade)

In Entity Framework Core.

Remove all files from the migrations folder. Type in console dotnet ef database drop -f -v dotnet ef migrations add Initial dotnet ef database update (Or for Package Manager Console) Drop-Database -Force -Verbose Add-Migration Initial Update-Database

UPD: Do that only if you don't care about your current persisted data. If you do, use Greg Gum's answer

To fix this, You need to:

Delete all *.cs files in the Migrations Folder. Delete the _MigrationHistory Table in the Database Run Enable-Migrations -EnableAutomaticMigrations -Force Run Add-Migration Reset

Then, in the public partial class Reset : DbMigration class, you need to comment all of the existing and current Tables:

public override void Up()
{
// CreateTable(
// "dbo.<EXISTING TABLE NAME IN DATABASE>
// ...
// }
...
}

If you miss this bit all will fail and you have to start again!

Now Run Update-Database -verbose

This should be successful if you have done the above correctly, and now you can carry on as normal.

Considering this still shows up when we search for EF in .NET Core, I'll post my answer here (Since it has haunted me a lot). Note that there are some subtleties with the EF 6 .NET version (No initial command, and you will need to delete "Snapshot" files)

(Tested in .NET Core 2.1)

Here are the steps:

Delete the _efmigrationhistory table. Search for your entire solution for files that contain Snapshot in their name, such as ApplicationDbContextSnapshot.cs, and delete them. Rebuild your solution Run Add-Migration InitialMigration

Please note: You must delete ALL the Snapshot files. I spent countless hours just deleting the database... This will generate an empty migration if you don't do it.

Also, in #3 you can just name your migration however you want.

Here are some additional resources: asp.net CORE Migrations generated empty

Reset Entity Framework 7 migrations

Delete the Migrations Folder, Clean then Rebuild the project. This worked for me. Before Clean and Rebuild it was saying the Migration already exists since in its cached memory, it's not yet deleted.

In EntityFramework 6 please try:

Add-Migration Initial

in order to update the initial migration file.

My problem turned out to be that I manually removed the Migrations folder. I did that because I wanted to back up the contents, so I simply dragged the folder out of the project. I later fixed the problem by putting it back in (after making a backup copy), then removing the Migrations folder by right-clicking it in Solutions Explorer and choosing Delete from the popup menu.

In EF6

Delete all your files in 'migrations' folder... But not the 'initial create' or 'config'. Delete the database. Now run Add-Migration Initial. Now you can 'update-database' and all will be well.

This method doesn't require deleting of the __MigrationHistory table, so you don't have to put your hands on the database on deploy.

Delete existing migrations from the Migrations folder. In Package Manager Console run Add-Migration ResetMigrations Clean migration history in the Up() method:

/// <summary>
/// Reset existing migrations by cleaning the __MigrationHistory table
/// and creating a new initial migration with the current model snapshot.
/// </summary>
public partial class ResetMigrations : DbMigration
{
    public override void Up()
    {
        Sql("DELETE FROM [dbo].[__MigrationHistory]");
    }

    public override void Down()
    {
    }
}

If you know your db and code are synced and now just hung up on something simple like migrations trying to duplicate tasks, the easiest way to start over migrations without losing data is to:

Delete your Migrations folder in VS. Create a new migration (e.g. add-migration InitialCreate) Delete all but the first row from the __EFMigrationsHistory db and change the first row value to your first migration name with the date code (e.g. 20220510060015_InitialCreate)

If you don't know the ProductVersion for the migration table, you can find it in the Designer or Snaphot .cs files in the newly created Migrations folder.

Now, when you run update-database, it should complete without erroring (and perform no tasks). This might be a good way to also get the most clean SQL migration script for an initial production environment if you were doing a bunch of renaming, dropping, tables, columns, etc. in your early migrations.

If your code and db are not in sync, depending on how much data you're dealing with and how out of sync they are, it's probably best to perform steps 1 and 2 above, then backup the db and drop it and let migrations recreate it all again from scratch, then restore the data.

Microsoft: Managing Migrations - Resetting all migrations

To avoid the steps above, sometimes if a migration blows up midway through, you have to step through a migration and comment out each migrationBuilder block that's already completed (in the order they were created), especially if it's not clear from the migration error. So you can look at your db and see that tables, columns, FKs, indexes, etc. that have been dropped, renamed, created, etc. and then just go down the list of migrationBuilder blocks and step through the migration (comment out the completed steps, run update-database again, repeat). When you're done, uncomment everything.

Another common error you might run into if there's already data in the table and you're trying to add a FK constraint:

Cannot add or update a child row: a foreign key constraint fails (Database1.#sql-alter-d9b-445b, CONSTRAINT FK_TableA_TableB_TableBId FOREIGN KEY (TableBId) REFERENCES TableB (`TableBId)

The table you are trying to create a FK constraint for, it's FK constraint column doesn't match anything in the PK column of the primary table. It's best to prepare for this in advance by creating the PK table first with a default value placeholder, but if you already received the error then here we are. The easiest way to fix this to avoid some of the more drastic steps above is to:

Check to see if the FK column got created and if it assigned a default value (e.g. in TableA, FK constraint TableBId = "0"). Modify the PK table (or create it first) with a default PK Id record of whatever value was assigned in step 1 (e.g. in TableB, create a record with TableBId = "0"). Comment out everything before the migrationBuilder.AddForeignKey block that errored out and run update-database again. The migration should create the FK constraint now and complete. Uncomment everything.

In Net Core 3.0:

I was not able to find a way to Reset Migrations.

I also ran into problems with broken migrations, and the answers provided here didn't work for me. I have a .Net Core 3.0 web API, and somewhere in the last month I edited the database directly. Yes, I did a bad, bad thing.

Strategies suggested here resulted in a number of errors in Package Manager Console:

A migration of that name already exists

Could not find the snapshot

'Force' is not a recognized parameter

Granted, I may have missed a step or missed clearing out the correct files, but I found that there are ways to clean this up without as much brute force:

Remove-Migration from the PMC for each migration by name, in reverse order of creation, up to and including the broken migration

Add-Migration to create a new migration which will be the delta between the last good migration up to the current schema

Now when the web API is started with an empty database, it correctly creates all the tables and properties to match the entity models.

HTH!

UPDATE 2020 => Reset Entity-Framework Migrations

Add-Migration Initial -Context ApplicationDbContext

ApplicationDbContext => Your context.

But if you need only update a identity schema existent, try it: https://stackoverflow.com/a/59966100/4654957

VSC(Visual Studio Code) -- .Net Core

1.Delete the state: Delete the migrations folder in your project;

2.Delete the __MigrationHistory's records in your database;

3.dotnet ef database drop -v then Are you sure you want to drop the database '<your-database' on server '.'? (y/N) Write "N"

4.dotnet ef migrations add Initial then the code of the 20211014110429_initial class Write to __MigrationHistory's

Enable-Migrations -EnableAutomaticMigrations -Force