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

EF Core 2 Migrations in VSTS CD Release #9841

Open
footedr opened this Issue Sep 18, 2017 · 17 comments

Comments

Projects
None yet
@footedr
Copy link

footedr commented Sep 18, 2017

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

This comment has been minimized.

Copy link
Member

ajcvickers commented Sep 18, 2017

@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

This comment has been minimized.

Copy link
Author

footedr commented Sep 19, 2017

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

This comment has been minimized.

Copy link

broersa commented Oct 6, 2017

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

This comment has been minimized.

Copy link
Member

bricelam commented Oct 9, 2017

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

@yzorg

This comment has been minimized.

Copy link

yzorg commented Dec 7, 2017

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).

@ajcvickers ajcvickers modified the milestones: 2.1.0-preview1, 2.1.0 Jan 17, 2018

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Mar 4, 2018

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:

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

This comment has been minimized.

Copy link
Contributor

ErikEJ commented Mar 4, 2018

Maybe someone in the Community could publish a VSTS extension?

@yzorg

This comment has been minimized.

Copy link

yzorg commented Mar 8, 2018

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?

@ajcvickers ajcvickers modified the milestones: 2.1.0, 2.2.0 Mar 16, 2018

@ajcvickers ajcvickers modified the milestones: 2.2.0, Backlog Apr 9, 2018

@footedr

This comment has been minimized.

Copy link
Author

footedr commented Apr 12, 2018

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

This comment has been minimized.

Copy link
Author

footedr commented Apr 13, 2018

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

@Relic79

This comment has been minimized.

Copy link

Relic79 commented May 15, 2018

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

This comment has been minimized.

Copy link

broersa commented Jun 8, 2018

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

This comment has been minimized.

Copy link

barmyard commented Jun 11, 2018

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

@bricelam

This comment has been minimized.

Copy link
Member

bricelam commented Jun 11, 2018

new MyDbContext().Database.Migrate();
@bennettfactor

This comment has been minimized.

Copy link

bennettfactor commented Jun 14, 2018

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

This comment has been minimized.

Copy link
Member

bricelam commented Jun 18, 2018

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

@johnnyreilly

This comment has been minimized.

Copy link

johnnyreilly commented Jun 24, 2018

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.