Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Introducing Slide Speaker: Videos with Voice-over from your PowerPoint and Google Slides Presentations

Deploy Entity Framework Core 2.0 Migrations from a DLL


(UPDATE 7/5/2018: If you’re using EF Core 2.1, you’ll probably want to read the updated version of this post.)

In a previous blog post, I discussed how difficult it is to deploy Entity Framework Core migrations from the compiled binaries of your project.  It’s still difficult to do.  You might be thinking, “well, why even bother?  Just deploy using the original project source code.”  You could do that but if your team does automated builds, automated deployments, and/or continuous delivery, then you probably won’t have access to that source code by the time you’re ready to actually deploy the code.  This is a good thing — build once, deploy multiple times to multiple environments.

There are a couple of options on how to deploy EF Core 2 migrations using just the DLLs and not the project source code.

Option #1: TFS / VSTS Extension

If you’re using Team Foundation Server (TFS) or Visual Studio Team Services (VSTS), I’ve written a build/release extension that you can use to make deploying EF Core migrations easy.  It’s free.  Go download and install this extension.  After you’ve installed that extension, you can add the Deploy Entity Framework Core Migrations step to your build definition or release definition.

Option #2: Batch Script

I originally wrote a batch script for EF Core v1 and included it in that blog post.  Basically, what the script does is take the output of “dotnet ef database update –verbose” and reproduce what EF Core is doing when it deploys your migrations using the actual code from the project.  The script works pretty well apart from how hard it can be to locate EF Core’s ef.dll.  With EF Core 2, the underlying syntax has changed a bit so I’ve written up a new batch script.

Here’s a link to download the EF Core 2 migration deploy script.  (Are you using EF Core 2.1?  You might want to check this out instead.)

Anyway, I hope this helps.

-Ben

 

— Looking for help with Entity Framework Core?  Need some assistance getting EF Core working with your team’s DevOps pipelines?  Want someone to come help your team figure out why integrating, building your code, and deploying your apps is so difficult and make it a whole lot less difficult?  We can help.  Drop us a line at info@benday.com.   

 

SUBSCRIBE TO THE BLOG


10 responses to “Deploy Entity Framework Core 2.0 Migrations from a DLL”

  1. […] [Updated 4/27/2018 — Added an EF Core 2 version of this script in a new blog post.] […]

  2. Jeremy Holovacs Avatar

    How do you tell where the deps.json file is?

  3. Guilherme Avatar
    Guilherme

    Hello,
    The batch works like a charm, but, I ain’t being able to use it on my CD step properly because for some reason the ef command gets stucked after ending it. On the task manager, there is a task “.NET Core Host” always running, that when ended unstuck, but also breaks the CD process. Any insight on that issue?
    thxs

  4. benday Avatar
    benday

    Well, that stinks. I’m going to reply to you by email. Hopefully, you can send me a screenshot.

  5. Guilherme Avatar
    Guilherme

    https://imgur.com/a/Qf9t0J2

    If I end this “.Net Core Host task”, the console unstucks. There are no other visible errors on screen

  6. Guilherme Avatar
    Guilherme

    https://imgur.com/a/v9p2TJA

    I did some minor changes (mostly for the dll path) to execute on the build machine

  7. toralux Avatar

    What about dotnet core 2.1 where ef is not a global tool? How will this script be with dotnet core 2.1 and ef core 2.1? (Also the VSTS script “Deploy Entity Framework Core Migrations” should be updated to reflect this)

    1. Ben Day Avatar

      Yah. That script may or may not work under EF Core 2.1. I haven’t tested it extensively yet but I’m working on it.

      So far, it seems like stuff works ok but getting the location of ef.dll still tricky…and that’s the real problem with this. It’s that *one* *silly* *hard-to-find* DLL that needs to be referenced.

  8. Rick Avatar

    First of all, thank you for the script!
    Looks like PathToNuGetPackages_Fallback2 is not used in the script, though. I See PathToNuGetPackages_Fallback1 being used twice.

  9. gijswijs Avatar
    gijswijs

    Thank you for this. A possible improvement: Add the possibility to add command line arguments. (I need this, because I have multiple db contexts, so I need to pass along the –context parameter

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.