Develop Reference

Which migration files can safely be deleted

I'm creating a new code-first Web application but using the code from another application as a starting point. But I'd prefer to delete all the unneeded migrations from the new project.
Currently, my migrations look like this:
I'm pretty sure that I need to keep ApplicationDbContextModelSnapshot.cs and ApplicationDbContext.cs.
So here are my question is: Can I safely delete all the other migration files?
Note: There is no change I will want to revert migrations in the new application, so that is not a concern.

To summarize your question, you'd like to have a clean slate and not have all the migrations you've accrued over time polluting your migrations folder. I've often needed to do this myself when starting a new project and iterating a lot before being satisfied with my final schema.
The good news is that Entity Framework supports this natively out of the box, with just one caveat: if you ever hand-roll your own migrations (by calling Add-Migration and then editing the resultant migration file), perhaps to add a custom index for perf reasons, you'll have to make sure to recover those in this process.
All you have to do is delete your entire migrations folder (including the snapshot) and start over as though you were creating the project from scratch. Typically when you create your first migration, you've already defined a few entities (that's why you want to create the migration, after all); you're just taking that to the next level and want your entire database in that migration.
Once you've deleted your migrations folder, EF no longer thinks your project has migrations at all -- like I said, you're starting from scratch. So all you have to do is call Add-Migration [MigrationName] (i.e. Add-Migration InitialMigration) and it will scaffold the migration with everything needed to create your whole database.
Note: In my comments, I suggested you would need to call Enable-Migrations first, but that is evidently no longer necessary so you can just jump right into calling Add-Migration.

Why not just delete them and add an empty migration to check? If it breaks then you have your answer. Then just restore from version control.
But what Kirk Woll said is correct. Keep your ApplicationDbContext and add an intial migration.

EF Core proper way to delete uncommitted migration

Environment: .NET Core 3.1 with EF Core
Short story: two migrations (A and B) were made. B is based on A. But update-database has not been executed for both A & B. A was deleted. Is there a way to revert A & B?
Long story: I think I did something stupid. I added a class in the code, then did add-migration (let's say it's migration A). After inspecting the generated migration class, I went back to make some changes. Because I haven't run update-database yet, I deleted migration A, then ran another add-migration, got migration B. Then I found out B is based on A. Deletion of migration A doesn't clear the migration.
Further research I found the migrations, even not updated to database, are kept in the MyDBContextModelSnapshot.cs file. Is that's how EF keeps track of it? I can't run update-database now because migration A is missing. Applying migration B will just cause an error in database.
My question is, instead of going into MyDBContextModelSnapshot.cs and manually revert it to before migration A and redo a migration, is there a way to fix this problem?
Thank you.

After some research, I simply executed this command to remove both A & B, even though the migration file of A has been deleted (and I didn't find it in recycle bin).
Remove-Migration
Then by using "add-migration" ef core created correct migration script.
Thank you.

The problem is indeed in the snapshot file, and you need to revert it to its state before A was added. Then you can add B and it will create all the new changes that were previously in A. This should do the trick even without the migration files:
dotnet ef database migrations remove B
dotnet ef database migrations remove A
dotnet ef database migrations add B
If it throws errors and you have source control this should also be a quick revert, if not, you should setup source control to prevent this type of thing. Committing early and often is a good practice for individual developers as well as teams, and it makes undoing mistakes trivial.
Finally, if the commands don't work and you don't have an earlier copy, you can use a previous migration. If you had a migration Z before adding A, you can copy the content of Z.Designer.cs to the snapshot (don't change the class name or imports). The migration designer is how EF tracks the changes, and it is applied to the snapshot when the migration is added. This is the same as manually reverting the snapshot, but less chance for error.

EF creates InitialCreate in MigrationHistory then migration is turned on & InitialCreate has a new MigrationId causing pending migration issue

I have two solutions, the base solution with no migrations(which is in production, so I can not wipe the data) and now I have branched of this to set up migrations and make some model changes.
First I need to set up migrations on the branched solution (second solution) so that I can apply the model changes so I:
Turn on migrations which auto creates an InitialMigration
Enable-Migrations -ContextTypeName Context
Make a blank migration based on the suggestion from https://www.apress.com/gp/blog/all-blog-posts/secular-trends-for-the-cloud/12097630
Add-Migration InitialBlank -IgnoreChanges
Update Database * update-database*
Make my model changes
Add a migration containing my model changes * Add-Migration add_entity*
Run Update-Database
So I delete the database created as I need to run the first solution to create the initial db setup (to mimic live).
When I run the first solution it creates an entry in MigrationsHistory table named InitialCreate (201807061432030_InitialCreate), which has been auto created. I then run update-database on the second solution which applies my model changes fine although their are discrepancies in the InitialCreate MigrationId.
Migration entries in my second solution (in order they were created and the order they are in the solution):
- 201807061257015_InitialCreate
- 201807061315294_InitialBlank
- 201807061323086_add_entity
Migration entries in the migration history table after running the first then second solution:
1 | 201807061315294_InitialBlank
2 | 201807061323086_add_entity
3 | 201807061432030_InitialCreate
The second solution runs fine but when I try to add any data I get System.InvalidOperationException: 'The model backing the 'Context' context has changed since the database was created. Consider using Code First Migrations to update the database.
I have tried to create another migration on the second project to make sure their are no model changes that have not been migrated (their shouldn't be) but I get an error.
Unable to generate an explicit migration because the following explicit migrations are pending: [201807061257015_InitialCreate]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
My questions:
How do I resolve the MigrationId mismatch? As the first solution did not have migrations turned on and when I do turn them on (in the second solution) it creates a new id.
Could the exception System.InvalidOperationException: 'The model backing the 'Context' be thrown by the MigrationId mismatch or could anyone point me at why this could be happening? I have had a look into this error but the solution's I found don't seem to work:
Deleting the migrations history table is no good as I can not do this in production because of customer data.
The other solution I found of adding Database.SetInitializer(null); to global.asax seems to make no difference.
Why does the order of my migrations look different once they have been applied in the migration history table?
Thanks in advance!

I am not sure if this will work but I think I may need to manually delete the first InitialCreate and edit the db entries to reflect the correct InitialCreate. Based of this SO question I just found https://stackoverflow.com/a/13108243/3172635.
I will have to try this Monday though.
Edit: I first tried deleting the InitialMigration entry in the _MigrationHistory table but this does not work as it tries to apply the InitialMigrations again but cant as the tables are already created. So what I did was update the MigrationId for the InitialMigration entry to reflect what it was in the new project.
The sql I used:
SET MigrationId='201807061257015_InitialCreate' WHERE MigrationId = '201807061432030_InitialCreate'

EF Migration object already exists error

I am working on an ASP.NET MVC project with Entity Framework with code first from database. I get the models for each table in the database. I made some changes in the models, enabled migrations and when I initial the migration I get an error:
There is already an object named 'TableName' in the database."
I tried with update-database -force but didn't help. The initial migration creates the tables that already exist!
How to make the initial migration apply the changes on the models and not create the tables from beginning?
And what is the best practice to sync changes between database and models in this case?

try to Run the
Add-Migration InitialCreate –IgnoreChanges
command in Package Manager Console. This creates an empty migration with the current model as a snapshot. and then Run the
Update-Database
command in Package Manager Console. This will apply the InitialCreate migration to the database. Since the actual migration doesn’t contain any changes, it will simply add a row to the __MigrationsHistory table indicating that this migration has already been applied.
see this
then change your models and add migration.
another approach is to simply comment all the code on up and down methods

Best and working For me idea is to comment all the code in UP and Down functions of Initial migration file and then fire
dotnet ef database update this should work fine,make sure you update migration before commenting out initial migration

If none of those answers work for you, you may check if in your code you use the method
context.Database.EnsureCreated()
Be aware that that method doesn't apply any migrations
(source) (you can check this making a sql query to the database and like "select * from __EfMigrationHistory" and be sure that there are no migrations on that database.
EF provide a really good method to help this that is
context.Database.Migrate()
that no only it will ensure that you have a database, but also use migrations and migrate yout db to the last version.
Hope it helps

This error appears when you deleted previous migrations and your new migration try to create new table that already exist. Recover previous migration and everything will be ok.

Amr Alaa solution works, but the database didn't migrate to the latest model.
Here's how it worked (using automatic migration) :
Delete Migrations folder
Execute enable-migrations
Set this two properties to true in the newly created Configuration.cs
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
}
Execute Update-Database -Force
Your database will be updated to latest scheme and ready.
hope this helps.

Code first migrations - how to display pending model changes?

I'm using code first migrations. Is there a way to display pending model changes in package manager console before I scaffold a new migration?

The accepted answer tells how to get the SQL for a already scaffolded model change before applying to the database.
The original question regarded model changes pre-scaffolding (i.e. changes in the model since the last "add-migration" before running the next "add-migration" ...)
To that answer i will just say: scaffold anyway, that gives you your preview. By that i mean, run "add-migration preview" or something similar, it will create the scaffolded migration with the model changes that you are interested in. Then just delete if from your solution ...
The point here is that there is no need to "preview" when actually "doing" can be quickly undone. Some might think deleting a scaffolded migration version from the migrations section of the solution would break something, but no it is very well supported.
You can even test scaffold, then create the sql script as Colin suggest in his answer, to get the full SQL. Still nothing has been done at this point, so delete the migration version if you'd like.

There is no way that I know of to view pending changes in the model before scaffolding the migration, but I can't think of a reason not to scaffold the migration using Add-Migration so that the pending changes can be viewed in the migration file. There is no need to apply those changes to the database and the scaffolded migration can always be deleted.
Once the migration is scaffolded, if you use Update-Database -Script entity framework generates a SQL script rather than executing the changes directly.
You can get help on the EntityFramework in the package manager using get-help EntityFramework
And you can get help on the Update-Database command using the following:
get-help Update-Database
get-help Update-Database -detailed
get-help Update-Database -full