Running EF core command 'update database' in .NET core 2.2 app is applying an old migration instead of the current one

Question

I'm working on a .NET Core version 2.2 app (with Angular), which uses EF Core (code first). It's been an existing project for a few years, I've cloned it about a month ago. There are lots of previous migration files all which seemingly have been applied already.

I made some changes to a model, updated the context, and created a new migration using:

dotnet ef migrations add AddAssignmentEndDateToSMEAssignment

Migration file created no problem, context snapshot and everything looks good. I run this next:

dotnet ef database update

And I get the following error:

> Applying migration '20200323181854_userProfileUpdate'.
Failed executing DbCommand (35ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
CREATE TABLE [nssr_roles] (
    [role_name] varchar(255) NOT NULL,
    CONSTRAINT [PK_nssr_roles] PRIMARY KEY ([role_name])
   at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action 1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)  
   at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)
   at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource 1 completion, Boolean sendToPipe, Int32 timeout, Boolean asyncWrite, String methodName)
   at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.Execute(IRelationalConnection connection, DbCommandMethod executeMethod, IReadOnlyDictionary 2 parameterValues)
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary 2 parameterValues)
   at Microsoft.EntityFrameworkCore.Migrations.MigrationCommand.ExecuteNonQuery(IRelationalConnection connection, IReadOnlyDictionary 2 parameterValues)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.MigrationCommandExecutor.ExecuteNonQuery(IEnumerable 1 migrationCommands, IRelationalConnection connection)
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
   at Microsoft.EntityFrameworkCore.Design.Internal.MigrationsOperations.UpdateDatabase(String targetMigration, String contextType)
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.UpdateDatabase.<>c__DisplayClass0_1.<.ctor>b__0()
   at Microsoft.EntityFrameworkCore.Design.OperationExecutor.OperationBase.Execute(Action action)
ClientConnectionId:ff4b615f-69a6-450e-9c8e-4f3e5de4497c
Error Number:2714,State:6,Class:16
There is already an object named 'nssr_roles' in the database.

So it's trying to apply an old migration (20200323181854_userProfileUpdate - one from 2020 no less) which is dealing with a completely different table (nssr_roles). I know someone who was working on this app made a new migration maybe 3 weeks ago so it's not that this one was pending. I also tried the below commands, same thing:

dotnet ef database update 20220506044703_AddAssignmentEndDateToSMEAssignment

&

dotnet ef database update AddAssignmentEndDateToSMEAssignment

I tried removing my newly added migration, then once it was removed I ran the remove again to see if there was anything pending:

dotnet ef migrations remove

But there wasn't, it showed the latest applied migration (the one my colleague did 3 weeks ago) with a message saying it was already applied.

What is happening here and what can I do to fix this? I don't want to delete anything in the database so I don't want to delete migrations and start from scratch. Can something go wrong when doing migrations and then pushing to git, causing whoever pulls it to have issues?

I know its an old version by the way, an update should happen down the road

Answer 1

So I learned our team does it differently: Instead of running that update command they do:

dotnet ef migrations script [lastMigration] [newMigration]

so it doesn't automatically update the database like the update command would, but it outputs you an SQL script that you run within your database once you confirm the script is doing what it should be doing. It seems less intuitive to do it this way but apparently it adds a bit of safety if you have a lot of foreign keys etc.

Still not sure why the migration in question that was coming up (old one) wasn't in the history table, but this approach worked.