Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
EF Core 2 Migrations in VSTS CD Release #9841
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/).
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?
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
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!
I have run into this issue on the hosted 2017 build agent, and have worked around it. Here is what I have found:
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.