Running migration on published dll

[mhamri]

Currently, we are using something like this to avoid copy the migration files into the production.

dotnet exec --runtimeconfig ./Company.App.runtimeconfig.json --depsfile ./Company.App.deps.json C:\Users\devUser\.nuget\packages\microsoft.entityframeworkcore.tools\2.0.3\tools\netcoreapp2.0\ef.dll --verbose database update --assembly ./Company.App.dll --startup-assembly ./Company.App.dll --data-dir ./

but with moving the efcore as a global tools i wonder how this command should look like.

with having the ef as global tool, i tried these and all failed

dotnet ef Company.App.dll database update
dotnet ef database update --assembly Company.App.dll --stratup-assembly Company.App.dll

[bricelam]

We've considered it. One hang up I have is that global tools require the .NET Core SDK. I imagine most production environments would only want to install the .NET Core runtime (not the entire SDK)

[bricelam]

Previously discussed in #6313

[mhamri]

@bricelam thanks, but #6313 is closed and it's for 2017 when there weren't any separate ef core global tools.

my problem isn't installing the SDK, but I prefer don't pull our code for the sake of migration. though not installing the SDK is an advantage

[bricelam]

I wonder if we could make a single-file executable to help with this scenario. Doing the equivalent of --runtimeconfig and --depsfile would be tricky, but maybe we could try using AssemblyLoadContext again--it has come a long way since we first tried.

[acds]

Seems other have solved this https://www.benday.com/2018/07/05/deploy-entity-framework-core-2-1-migrations-from-a-dll

In updating the script for SDK 3.1.0.100, I ran it to a weird observation...

Givne a dotnet tool install --global dotnet-ef

If seems that the ef.dll deployed as part of 3.1.0 is actually a netcoreapp2.0 with the dll being deployed Into the package cache as:

/root/.nuget/packages/microsoft.entityframeworkcore.tools/3.1.0/tools/netcoreapp2.0/any/ef.dll

In a clean 3.1.0.100 SDK environment this will then not work with the following error:

It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.0.0' was not found.

[bigolewannabe]

We've considered it. One hang up I have is that global tools require the .NET Core SDK. I imagine most production environments would only want to install the .NET Core runtime (not the entire SDK)

Our experience is that we're connecting to the database from a build server which would be expected to have the SDK. I think that's a common scenario. It's seems to me it's not likely we'd run that on a non-development machine.

[acds]

I’d concur and suggest that one is very likely to be running this from ones CI/CD environment that is highly likely to have the full SDK installed...

[bricelam]

An alternative idea to this is Migrations Bundles (issue #19693)

[majorimi]

You can try out one of these suggested solutions on Stackoverflow.

[ajcvickers]

Note from triage: bundles covers the common scenarios here, and we don't plan to do anything else in this space.