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.
Anyway, I hope this helps.
— 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 email@example.com.