.NET Core 2.0应用合并已部署数据库迁移的官方方法咨询

Hey James, great question! Consolidating dozens of EF Core migrations into a single baseline is totally doable, especially since all your existing migrations are already live in production. Let's walk through the safe, EF-compliant steps to make this happen:

First, we need to make sure our local development environment matches production perfectly:

• Run dotnet ef database update locally to ensure all existing migrations are applied (this should be a no-op since you said everything's deployed, but it's a safe check).
• If you want to be extra thorough, restore a backup of your production database to your local environment—this guarantees your DbContext model is 1:1 with what's running in production.

We'll create a new migration that represents the current state of your database, not all the incremental changes from the past 30+ migrations. Use the --ignore-changes flag to tell EF Core your model and database are already in sync:

dotnet ef migrations add PhaseOneMigrations --ignore-changes

This generates a migration with empty Up() and Down() methods—this is our new starting point. The real magic is that it updates the YourDbContextModelSnapshot.cs file to reflect the full current schema, which EF uses to track future changes.

Now we can remove all those old migration files to declutter your project:

• Delete every file in your Migrations folder except for:
  • The new PhaseOneMigrations.cs and PhaseOneMigrations.Designer.cs
  • The YourDbContextModelSnapshot.cs file (don't touch this—EF needs it!)

Production's __EFMigrationsHistory table has records for all 30+ old migrations. We need to replace those with our new baseline to avoid conflicts when deploying future migrations:

1. First, back up your production database—this is non-negotiable.
2. Run this SQL on your production database (replace placeholders with your actual values):

   -- Delete all old migration records
   DELETE FROM __EFMigrationsHistory;
   
   -- Insert the new baseline migration
   INSERT INTO __EFMigrationsHistory (MigrationId, ProductVersion)
   VALUES ('[YOUR_MIGRATION_ID]', '2.0.0');
   

   You can find [YOUR_MIGRATION_ID] in the top of your PhaseOneMigrations.cs file—it looks like [Migration("20240520123456_PhaseOneMigrations")].

Let's test to make sure future migrations will behave correctly:

• Make a tiny change to your DbContext model (e.g., add a string TestField { get; set; } to one of your entities).
• Run dotnet ef migrations add TestValidationMigration—this should generate a migration that only includes the new test field, not the entire schema.
• Apply it locally with dotnet ef database update to confirm it works, then you can delete the test migration if you want.

• Never modify production's schema directly—we're only touching the migration history table here, not the actual database structure.
• For your team: Make sure everyone pulls the updated Migrations folder and snapshot file from source control to avoid merge conflicts.
• This approach is fully compliant with EF Core's migration system because we're respecting how EF tracks applied migrations via the __EFMigrationsHistory table.

内容的提问来源于stack exchange，提问作者James L.