dotnet ef migrations has-pending-model-changes should honour the --project argument

[stevecwilkinson]

What problem are you trying to solve?

The dotnet ef migrations has-pending-model-changes command is a great recent addition (thanks!) but it does not appear to honour the --project flag.

This is a problem for developers needing to use separate migration assemblies (as per https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/providers, using a single DbContext). The following works nicely:

dotnet ef migrations add Migration_1 --project ..\migrations\SqlServer\SqlServer.csproj -- SqlServer

(where SqlServer.csproj is the target migration assembly, and the -- SqlServer is passing 'SqlServer' as an argument to the code that creates the DbContext. I have a similar line with the Postgres in place of SqlServer.)

but the following doesn't:

dotnet ef migrations has-pending-model-changes --project ..\migrations\SqlServer\SqlServer.csproj -- SqlServer

Instead of checking the migration assembly specified, the check for up-to-date migrations appears to be made in the assembly that contains the DbContext definition.

(I umm'd and ahh'd about raising this as a bug report but as it is a relatively new feature which was a pleasant surprise to find implemented, it seemed a bit of a heavyweight approach. Happy to re-raise as a bug if that would be better.)

Describe the solution you'd like

This may not be deemed a high priority issue as possible separate migration assemblies aren't being widely used. It would be good to see it added to the backlog, but meanwhile, if some sample code could be provided that maybe re-uses the existing implementation but with separate migration assembly support, that would splendid.

MTIA.

[stevecwilkinson]

I've just hit the same issue for dotnet ef migrations script - this could be a real show-stopper. The documentation (which everyone seems to apologise for, indicates that the "common options" (including --project) apply to the script command...

[stevecwilkinson]

Turns out the issue for both these commands is that you must build the migration assemblies first. That way, the tool can inspect the assembly (as opposed to just the generated source code) and do the right thing.