dotnet ef6 (Migrations commands on projects without Visual Studio)

In EF Core, we introduced dotnet ef which enabled Migrations commands (Add-Migration, Update-Database, etc.) outside of Visual Studio and on other platforms like macOS and Linux.

As part of #231, we introduced the underlying ef6 command which is cross-platform but works directly with assemblies instead of project files (csproj, vbproj, etc). For example, the equivalent of Update-Database would be…

dotnet exec \
  --depsfile ./bin/Debug/netcoreapp3.0/MyApp.deps.json \
  --runtimeconfig ./bin/Debug/netcoreapp3.0/MyApp.runtimeconfig.json \
  ~/.nuget/packages/entityframework/6.3.0/tools/netcoreapp3.0/any/ef6.dll \
  --assembly ./bin/Debug/netcoreapp3.0/MyApp.dll \
  database update

Obviously, this isn’t very user friendly compared to a simple dotnet ef6 database update, but it is possible. You can also get the exact command to run by adding -Verbose to the PMC commands since they are also backed by this same underlying command.

Is this enough or should we introduce dotnet ef6? How many EF6 projects will be developed without using Visual Studio?

[marchy]

@ErikEJ this has nothing to do with Migrator.EF6.

This is a basic functionality of making ANY mutations to your data model, and Microsoft shouldn’t be relying on third parties to deliver mission-critical parts of their own frameworks/platforms.

We literally can’t add a column to our domain models without spinning up a Windows VM, developing in a duplicated repo/IDE and have been in this state of affairs for the past 2+ years. We’ve tried everything from buying multiple machines to deal with this, running boot partitions, and now slow and resource-eating VMs. We’ve exerted all sorts of needless engineering efforts for this, from splitting our servers into needlessly-isolated micro-services to reduce the impact of how many projects have to be stuck on .NET Framework/Windows environments, to forking and debugging 3rd party stop-gap solutions like Migrator.EF6 – let alone adopting and then fully-downgrading from EF Core due to the ridiculous unreadiness on that front that’s been the case along this whole journey (#side-vent).

The point is that .NET Core is ALL about running in non-Windows environments (read the mission/purpose) – literally ‘cross-platform’ and ‘command-line tools’ are two of the main stated goals lol

Quit defending the complete ball-drop on this. This needs to be resolved ASAP and without expecting the community to do Microsoft’s own internal development. Your defense/work-around mindset for this is only feeding the problem.

[tocsoft]

Seems a shame that dotnet-ef couldn’t just detect the correct entity framework version in play and execute the command against the correct ef backend underneath for you (even if it has to call dotnet build in the process to get hold of the latest dlls etc). Would be much better user experience instead of adding in a whole new tool with its additional cognitive load of a having to know/learn another new tool.