Add --connection parameter for Remove-Migration

[coreyfournier]

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. I have multiple projects, but a single .net core library contains the DbContext and migration files. This all works fine where I am able to specify the Context, Project, and Connection. Except for "Remove-Migration". It doesn't allow the parameter Connection. Because of this I have to default a connection in the DbContext.

Describe the solution you'd like

I would like to be able to specify the Connection like all other functions support in the Remove-Migration function

[jikuja]

Because #25252 was marked as duplicate of this:

dotnet ef migrations remove help documentation should be improved:

Revert the migration if it has been applied to the database. does not give any hint to user that argument is also used to ignore connection related issues.

[lauxjpn]

I second this issue. This always catches me cold once in a while when I just want to remove a migration and suddenly my database is being hit.

The default for dotnet ef migrations remove needs to not hit any database. An optional parameter to also change the database could be considered, but technically this is already covered by the dotnet ef database update command.

Generally, I think that only the dotnet ef database commands should be able to change a database.

[chrisfcarroll]

This is currently awful :-(

Sanity imho would be one of:

• accept and document a --connection parameter like migrations list does.
• or, rename the --force parameter to --offline and document it as such

[ska737]

The default for dotnet ef migrations remove needs to not hit any database.

This has gotten me a lot. I'm setting up the migrations before applying them (I'm migrating a project and am just trying to get the table definitions to match, not actually creating the database). I don't want to create the database just so I can remove the last migration that was not correct.

Generally, I think that only the dotnet ef database commands should be able to change a database.

This makes total sense. The only things that should even attempt to hit a database are the dotnet ef database commands. Everything else should be segregated.

[dhtek]

+1, this makes total sense ! We should be able to remove migration without database and doing the database update using the command dotnet ef database

[Erumer]

I completely agree: having migrations command act on code, and database on db would be much more clear