Search code examples
c#sql-serverentity-framework-coreef-code-firstentity-framework-migrations

Entity Framework Core using existing models and database , upgrading from .Net 4.8

I have upgraded a .NET Framework 4.8 site to .NET 6.0 using the migration assistant and a bunch of manual changes to fix stuff. I found that using Add-Migration doesn't work anymore. The migration assistant left the project using the pre-Core version of Entity Framework. I thought I'd try to upgrade to Entity Framework Core to get the project fully up to date.

The migration files are not even close to what Entity Framework Core needs and it occurs to me that I don't care about the migration files. I'm not going to be removing any of the migrations so the history is no longer relevant.

Is it possible with existing entities and an existing database to essentially reset Entity Framework Core such that it will allow me to create new migrations? It might be nice if it would build an initial create database migration that would be capable of building the database from scratch but that's not terribly important since this is a well established site. Granted, building from scratch could be handy for dev and testing but it's not required at this point - I could work on that bit later if needed.

Can I treat it like code first but delete all the migrations and clear the migrations table? Will it recognize that the entities already exist as tables in the database or will it want to build everything fresh?

Can I treat it like database first, have it build all the models then delete those models and use my own? I'm tempted to go that route, seems like the least likely to fail.

I searched for this a fair bit but when it involves migrating from .NET Framework to .NET Core and also involves Entity Framework Migrations I've found it hard to get rid of all the general version migration search hits to find what I really want.

Will any plan be sabotaged by the fact that I upgraded to Identity Core so the identity related entities are already out of sync with the database?

Solution

  • Here are the relevant bits from the link Ivan provided.

    Microsoft refers to this as squashing the migrations if you are trying to retain the existing data. They list the steps as:

    1. Delete your Migrations folder
    2. Create a new migration and generate a SQL script for it
    3. In your database, delete all rows from the migrations history table
    4. Insert a single row into the migrations history, to record that the first migration has already been applied, since your tables are already there.

    I had to modify the procedure above because it doesn't account for the change in the migration history storage. You may need to replace step 3 with:

    1. Drop __MigrationHistory from your database

    2. Create __EFMigrationsHistory as

      CREATE TABLE [dbo].[__EFMigrationsHistory] ( [MigrationId] NVARCHAR (150) NOT NULL, [ProductVersion] NVARCHAR (32) NOT NULL, CONSTRAINT [PK___EFMigrationsHistory] PRIMARY KEY CLUSTERED ([MigrationId] ASC) );

    Then proceed with step 4 from the original list. Note, for the ProductVersion field in __EFMigrationsHistory you can look in your initial migration's designer.cs file or in ApplicationDbContextModelSnapshot.cs after creating the migration.