Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running EF Core Migrations from DLLs on Linux #13339

Closed
mmillican opened this issue Sep 17, 2018 · 21 comments

Comments

Projects
None yet
8 participants
@mmillican
Copy link

commented Sep 17, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 17, 2018

@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

This comment has been minimized.

Copy link
Author

commented Sep 18, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 19, 2018

[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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2018

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

@mmillican

This comment has been minimized.

Copy link
Author

commented Sep 20, 2018

@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

This comment has been minimized.

Copy link
Member

commented Sep 20, 2018

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

This comment has been minimized.

Copy link

commented Sep 21, 2018

@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

This comment has been minimized.

Copy link

commented Sep 25, 2018

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

@mmillican

This comment has been minimized.

Copy link
Author

commented Sep 27, 2018

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

@scottaddie

This comment has been minimized.

Copy link
Member

commented Sep 27, 2018

@livarcocc @TheRealPiotrP Issue dotnet/cli#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

This comment has been minimized.

Copy link
Member

commented Sep 28, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 28, 2018

Don't try this at home

So can I publish it in a blog post?

@bricelam

This comment has been minimized.

Copy link
Member

commented Sep 28, 2018

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

This comment has been minimized.

Copy link

commented Sep 28, 2018

@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

This comment has been minimized.

Copy link
Member

commented Sep 28, 2018

So can I publish it in a blog post?

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

@bricelam

This comment has been minimized.

Copy link
Member

commented Sep 28, 2018

@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

This comment has been minimized.

Copy link
Member

commented Sep 28, 2018

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

This comment has been minimized.

Copy link
Author

commented Sep 28, 2018

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

@mmillican

This comment has been minimized.

Copy link
Author

commented Sep 28, 2018

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

Thanks for the help all!

cc @jcmiron

@ajcvickers

This comment has been minimized.

Copy link
Member

commented Oct 1, 2018

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: aspnet/EntityFramework.Docs#807

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.