Running EF Core Migrations from DLLs on Linux

[mmillican]

I'm currently working on setting up a build to our Linux EC2 instances via Code Deploy and have been having some issues getting EF Migrations to run.

Running dotnet ef database update -p ProjectName.Backend.Core.dll -s ProjectName.Backend.Api.dll produces the following:

/path_to/MyProject.Backend.Core.dll(1,1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 1, position 1.
Unable to retrieve project metadata. Ensure it's an MSBuild-based .NET Core project. If you're using custom BaseIntermediateOutputPath or MSBuildProjectExtensionsPath values, Use the --msbuildprojectextensionspath option.

What do I need to get migrations to run on Linux from a published output?

I've seen Ben Day's post about deploying from DLLs for EF Core 2.1, but this is for more of a Windows environment (both the batch script and file locations).

[ajcvickers]

@mmillican The concept should be the same as is described in the post. Are you asking for help converting the script to run in your Linux shell?

[mmillican]

@ajcvickers I can probably convert the script (at least the basics) if someone hasn't already.

My other question though is: how do I get the EF tools installed on the instance? EF isn't available as a global tool and these instances wouldn't have the Nuget packages installed on them.

[smitpatel]

From the blog post

One of the hardest parts of scripting this is trying to figure out where ef.dll is on disk. The script tries to find ef.dll in a couple different places but if it can’t find it, the script will fail. If you don’t want to deal with that uncertainty, you can now just manually put ef.dll into the same directory as the script and the script will use that copy.

That's it. Just copy over ef.dll file on your instance (probably alongwith the script) and use it directly.

[mmillican]

[Edited as I finally found the ef.dll file]

Are there any plans for making this easier in the future? This is incredibly frustrating and annoying.

[ajcvickers]

@benday Do you have anything describing more specifically how to do this on Linux, or would you consider adding it to your post?

[mmillican]

@ajcvickers @benday I ended up figuring this out yesterday and plan on doing a blog post soon.

Would be great to have this support built in.

[bricelam]

Note, the easiest way to get the command to run is to use dotnet ef database update --verbose and look for a line that starts like this:

dotnet exec --depsfile MyApp.deps.json --runtimeconfig MyApp.runtimeconfig.json ef.dll database update

[benday]

@benday Do you have anything describing more specifically how to do this on Linux, or would you consider adding it to your post?

@ajcvickers, I'd be happy to share more info about doing migration deploys with Linux. How can I help? What do you think is missing? What are you finding difficult and/or confusing?

[jcmiron]

I'm having the same issue, @mmillican did you create the blogpost yet?

[mmillican]

@jcmiron I'm hoping to have it ready this weekend.

[scottaddie]

@livarcocc @TheRealPiotrP Issue https://github.com/dotnet/cli/issues/2243 discouraged the use of dotnet exec. See Brice's comment above. Is this a case where exec absolutely must be used. I'm asking from a documentation perspective. If there are edge cases like this, maybe we should add a note to the CLI docs.

[bricelam]

Is this a case where exec absolutely must be used.

Yep. Don't try this at home, folks. It's dangerous, but we know what we're doing. .NET CLI team supervision is required. 😉

[mmillican]

Don't try this at home

So can I publish it in a blog post?

[bricelam]

The dirty details: We're effectively running ef.dll as if it was your app. We use your app's dependencies and your app's runtime config. If you're not careful you can run into missing or conflicting assemblies.

But yes, it's safe to run the command you see in --verbose. This is exactly what calling dotnet ef runs behind the scenes.

[livarcocc]

@bricelam you are giving away all our secrets man.

@scottaddie I am not sure this warrants document this or not. This is actually part of the host itself and not really the CLI, so I will let @jeffschwMSFT comment on it.

[bricelam]

So can I publish it in a blog post?

Absolutely. ef.dll was designed to be called with dotnet exec

[bricelam]

@scottaddie I wouldn't mention it in the docs. This is just implementation detail of the dotnet ef command. The blog post documents the manual steps you have to take for a super advanced scenario: Running EF Core migrations without the .NET Core SDK or your *.csproj file available.

[bricelam]

Note, our recommended approach is to generate SQL script on the dev box and run those on the server instead. At least until we have a good delivery mechanism for an EF tool that can run directly against assemblies.

[mmillican]

Thanks for the feedback @bricelam, @scottaddie and @livarcocc. Currently trying to update the post I have to mention these recommendations.

[mmillican]

The blog post has been published. If the team has any feedback, please let me know.

Thanks for the help all!

cc @jcmiron

[ajcvickers]

Thanks everyone for your input and contributions here. I'm closing this out now in favor of some remaining follow-up items on the relevant docs issue: dotnet/EntityFramework.Docs#807