Efcore: EF Core 2 Migrations in VSTS CD Release

[footedr]

Attempting to execute the following batch script that runs an EF Core 2 migration against published code in a VSTS continuous delivery release (adapted from Ben Day's article located here: https://www.benday.com/2017/03/17/deploy-entity-framework-core-migrations-from-a-dll/).

`set EfMigrationsNamespace=%1
set EfMigrationsDllName=%2.dll
set EfMigrationsDllDepsJson=%2.deps.json
set DllDir=%cd%
set PathToNuGetPackages=%USERPROFILE%.nuget\packages
set NuGetFallbackFolder="C:\Program Files\dotnet\sdk\NuGetFallbackFolder"
set PathToEfDll="C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.entityframeworkcore.tools.dotnet\2.0.0\tools\netcoreapp2.0\ef.dll"

dotnet exec --depsfile .\%EfMigrationsDllDepsJson% --additionalprobingpath %PathToNuGetPackages% --additionalprobingpath %NuGetFallbackFolder% %PathToEfDll% database update --assembly .\%EfMigrationsDllName% --startup-assembly .\%EfMigrationsDllName% --project-dir . --data-dir %DllDir% --verbose --root-namespace %EfMigrationsNamespace%`

This works locally, but fails in the hosted agent because it cannot find the location of %PathtoEfDll%. Where can I reliably locate the ef.dll on the hosted vs2017 build agent?

[ajcvickers]

@footedr Are you saying that ef.dll is not present on the disk after installation of the .NET 2.0 SDK? Have you checked whether it is under Program Files or Program Files (x86)?

[footedr]

Are you saying that ef.dll is not present on the disk after installation of the .NET 2.0 SDK? Have you checked whether it is under Program Files or Program Files (x86)?

Correct. I tried both Program Files and Program Files (x86).

[broersa]

I managed to find the ef.dll and copy it in my artifacts. But when I run it in a Release I get the following error: A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in...
Anyone?

[bricelam]

You may also need to copy ef.runtimeconfig.json...

[yzorg]

Just a comment / question: I have a legacy app I'm migrating to EF Core 2.0 and one of the first things I did was change migrations to use EF Core 2.0 migrations running at app startup. I was considering changing this to run migrations during VSTS CD Release instead, but it looks like there's a gap in VSTS support.

Anyone working with VSTS to make dotnet ef easier to run during release? I'd be willing to start that discussion (VSTS forum, or SO).

[johnnyreilly]

I'd just like to second what @yzorg said; I think it would be tremendous if deploying EF Core migrations was a "first class citizen" in VSTS.

I've found myself looking at various solutions:

• https://blog.bennymichielsen.be/2017/08/01/migrating-databases-with-ef-core-during-a-vsts-release/
• as well as the Ben Day one

In the end it proved too fiddly. I've moved to using migrations when the app starts up. I feel bad but I haven't succeeded with other avenues and I'm out of time. I need to ship.

This all feels harder than it ought to and I wonder if the team would consider giving this some love?

Thanks for all your work!

[ErikEJ]

Maybe someone in the Community could publish a VSTS extension?

[yzorg]

Maybe this will come with the Core 2.1 support for global installed tools? (Like npm install --global but for dotnet CLI tools.)

Any plans to add a migration tool as a Core 2.1 global CLI tool?

[footedr]

I have been using an on-prem agent to avoid this issue. But I recently tried the same release definition on the Hosted VS2017 agent and it worked fine and has been for several days.

Looks like it's resolved?

[footedr]

Nevermind. It worked on the hosted agent for 3 days, then when back to failing because it can't located ef.dll.

[Relic79]

I have run into this issue on the hosted 2017 build agent, and have worked around it. Here is what I have found:

• During release (no dotnet restore) the hosted 2017 build agent has Microsoft.EntityFrameworkCore.Tools.DotNet 2.0.2 in C:\Program Files\dotnet\sdk\NuGetFallbackFolder\

• During build, (having run dotnet restore), the version of the tooling used in the project can be found in %userprofile%.nuget\packages\Microsoft.EntityFrameworkCore.Tools.DotNet[package_version]

In order to restore during release to obtain the needed ef.dll version I would need to include something to restore against like the csproj. If I'm already pushing files into the artifact folder, I might as well look for the ef bits and copy them instead.

I have added a step during my build to copy the ef.dll from the %userprofile% into the build artifacts, then in the release phase, I extract the zip and use the ef.dll from the build with a modified/hardcoded version of Ben Day's script: https://www.benday.com/wp-content/uploads/2018/04/deploy-ef2-migrations.bat_.txt.

I am now working on a small powershell script to run that will parse the project files, get the tooling version, and then find the folder and copy the files so I can upgrade EF without breaking my build.

Not sure if this is useful or not but thought I would add my experience so far over the last few days.

[broersa]

I worked around by adding a dotnetcore consoleapp project where I run the migration via the Context. In the Build I build this consoleapp in the release I execute it.

[barmyard]

@broersa that seems like a clean solution to me.
Could you provide the code that's needed?

[bricelam]

new MyDbContext().Database.Migrate();

[bennettfactor]

It would be helpful to be able to run EF migrations against a target database via the dotnet ef command without needing access to the project source code.

[bricelam]

@bennettfactor We hope to provide more guidance around this as part of aspnet/EntityFramework.Docs#691

[johnnyreilly]

@barmyard I implemented @broersa's approach and blogged it here: https://blog.johnnyreilly.com/2018/06/vsts-and-ef-core-migrations.html