I am setting up an Azure Release Pipeline and I need to execute any pending DB Migrations as part of the release.
I have been scouring the internet for over an hour and everything I can find is about dotnet Core, while the database is EF6 on .Net Framework, not dotnet Core (I've done this several times before for Core).
The problem, as I see it, is that EF6 works using Visual Studio's built in Package Manager Console - This just doesn't exist in an Azure Pipeline; It's a Visual Studio weirdness.
There seems to be several ways I can skin this cat, in my head, but I can't figure out how to start with either of them within the context of the pipeline...
OPTION 1: Run the Migrations on the Pipeline - but... how?
OPTION 2: SQL Scripts - Requires running the Package Manager to generate them so they can be run (if I could do that on the pipeline then I'd just run it anyway so these would have to be created locally and committed with the code which is somewhat backward as a solution IMO)
OPTION 3: Write a console app - Do I really have to do this??
You can try Entity Framework Migration Extensions.
This task allows a Build / Release to provide database connection parameters and execute an Entity Framework 6 migration against the database.
Build your project to an output folder and include the migrate.exe executable that comes with Entity Framework 6.
Create an automated build that packages up your files and makes them accessible during a Release.
Create a Release definition for the relevant Build
Add an EF6 Migration task. Once that task is added to an environment within the release, you'll need to enter the appropriate parameters to configure it. All file path parameters should be within the file system for the build, none of them are for TFS source control paths.
You can also check this article.
The answer here is to use the ef6.exe command line tool and make sure it gets shipped with your build.
This could be useful to anyone here until Microsoft update the non-existent docs: http://github.com/dotnet/EntityFramework.Docs/issues/1740 - This contains a table with a kind of translation matrix between the two.
Related
I am working on an application that utilizes a database that often has tables added to it or modified. Is there a way I can regenerate the .edmx file as a build step or during compile time to add these new tables/modifications without manually running the wizard?
You can try to run sql scripts to insert/modify tables during build process.
Related extension:
ExecuteSqlScript
Run SQL Server Scripts Task
Or directly use PowerShell to Execute .SQL Files from Directory.
Reference below articles to change the database during build/release:
Build and Release Process for SQL Server Database
Scripts using Online TFS
Continuous Deployment of SQL Server Database Changes using Visual
Studio & TFS Release Manager
UPDATE:
Choosing the Update Model from Database is the best method for updating your EDMX. There are certain properties that don't get updated on the Conceptual layer.
See How do you update an edmx file with database changes?
Seems there isn't a good way to achieve that, however if the actions can be executed in command line, then we can add a step to run the command or script.
How to run those dotnet.exe ef <command> commands programmatically in .NET Core?
For example to add migration I'm running in terminal dotnet ef migrations add NewMigration and it will indeed create Migrations folder with migration classes, but to create new Migration (for example) programmatically from C# code?
Don't suggest Process.Start("cmd bla-bla") since code should be cross-platform and that dotnet ef runs some code from some EntityFrameworkCore package anyway. Question is what code?
EF Core API isn't really designed for the scenario, but if you want to do this anyways, you'll need to repeat the logic that "dotnet-ef.dll" does to gather project context and compilation output, and then instantiate and use MigrationsOperations manually.
See https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design.Core/Design/MigrationsOperations.cs and https://github.com/aspnet/EntityFramework/blob/1.0.0/src/Microsoft.EntityFrameworkCore.Design/Internal/OperationExecutor.cs
Use caution: these are "Internal" APIs, which means their usage may break from version to version. "dotnet ef" is going to change a great deal between the current release (1.0.0-preview2) and the next release. (For example, the entire tooling implementation will change. See https://github.com/aspnet/EntityFramework/issues/5334).
I'm building a Visual Studio 2010 solution through Python with a call to subprocess. When called directly from the command line it takes devenv.com ~15 seconds to start. But when called from Python this jumps up to ~1.5 minutes.
Naturally I'm hoping to remove that dead time from our build. So I decided to test out MSBuild.exe (from .NET 4). It looks like MSBuild.exe runs instantly. But... it seems to do a full build every time and not an incremental.
The command I'm using is
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" "C:\path\to\my\project.sln" /target:build /maxcpucount:8 /property:Configuration=Release
It seems like this should support an incremental build. But I've seen posts online indicating that msbuild may not be able to support a incremental build like this.
Is this possible? If so what am I doing wrong?
Update:
I've read into this a bit more. Based on
http://msdn.microsoft.com/en-us/library/ms171483.aspx
and
http://www.digitallycreated.net/Blog/67/incremental-builds-in-msbuild-and-how-to-avoid-breaking-them
It seems like I need the Input and Output properties set in my .vcxproj files. Checking out my files these are indeed missing.
When would they be generated? Most my .vcxproj files were converted over from Visual Studio 2008. But I also generated a new project which is missing the Input and Output properties as well.
Does VS2010 not create projects with these properties?
Update: We've since upgrade to VS 2013. Now msbuild supports incremental builds. Never got to the bottom of the VS 2010 issue.
I think that fact that Incremental builds are not supported is a false Statement from according to official sources,Managed Incremental Build this feature and was included in VS2010 SP1
We first introduced the managed incremental build feature in VS2008.
In VS2010, we were not able to re-implement the managed incremental
build feature with the build system moving to MSBuild. We received
strong customer requests for this feature. As a result, we
re-implemented this feature and it is included in VS2010 SP1.
Other Solutions I found on Web
Projects should build incrementally already (just make sure that you
do Build instead of Rebuild). The best way to check if incremental
building works is to run the build from the command line. The second
time you build it should take almost no time.
If things are still getting rebuilt, then perhaps you've modified
your projects in some way that's messing up with the build order.
Looking at the build logs (via the /v option) can help you poinpoint
what's going on.
Other reason which can cause problems with the incremental build is GenerateResource.TrackFileAccess PropertyThis API supports the .NET Framework infrastructure and is not intended to be used directly from your code.
Gets or sets a switch that specifies whether we should be tracking file access patterns.
In order to implement run and re-run my integration tests an indefinite number of times, I would like to make use of SSDT in VS2012 to publish to a LOCALDB file instance and run EF against that file during integration tests.
Few notes:
We are using EF Database first
We already have a SSDT project that we will use to deploy to a full
database in our different environments
I know that SSDT uses internally a LOCALDB instance to build/deploy/check for errors, so deploying to another custom localdb seems like it should make sense/be doable
Few questions:
Can I deploy to a specific LOCALDB file with SSDT?
Can I do this from the command line in order to automate it when I run integration tests?
Does this roughly seems like a good idea for integration tests with EF or is there a better way? ;-)
Thank you all
You can change the localdb for SSDT in the Debug options for the project. By default the debug options are set to the (localdb) instance and a DB name that corresponds to the project.
You may have more success with Publish Profiles if you're trying to push the project changes to a DB server. You can use those with SQLPackage to push the changes along with a known set of options to a pre-defined server/database.
You can definitely push the changes through a command line. We're doing it with MSBuild to generate a dacpac file, then SQLPackage to publish the changes from the dacpac to the appropriate server/database.
Can't say for sure on this one. If it works for you, it's likely a good start. We do DB development outside of EF and try to do that first rather than trust EF to generate a good relational model.
I have a handful of blog posts on SSDT SQL Projects at http://schottsql.blogspot.com/search/label/SSDT that might be helpful.
I have a test project which references another project, which in turn references a third project containing my Entity Framework 5.0 file (edmx). I find that I can run database-driven unit tests directly from Visual Studio, but when I run from mstest I get the following errors:
System.Data.Entity.Infrastructure.UnintentionalCodeFirstException:
Code generated using the T4 templates for Database First and Model
First development may not work correctly if used in Code First mode.
To continue using Database First or Model First ensure that the Entity
Framework connection string is specified in the config file of
executing application.
I have non-database connecting unit tests which run fine. I've fiddled with my various app.config EF connection strings and they seem to be OK (every tests runs fine on Visual Studio). The problem is when I run mstest from a command line on my desktop or on a build server. This is the command I use:
MSTest.exe /nologo /searchpathroot:"\Binaries"
/resultsfileroot:"\TestResults"
/testcontainer:"\Binaries\driver.orderedtest"
/testcontainer:"\Binaries\EF.DataAccess.dll"
/publish:"http://"
/publishbuild:"vstfs:///Build/Build/99" /teamproject:"ProjectName"
/platform:"Any CPU" /flavor:"Debug" /noisolation /detail:errormessage
/detail:errorstacktrace /detail:stderr
I have references to all dll's in the test project, as outlined here: Entity Framework custom tool does not correctly embed or load the model as resource files
I've been on this for a few days off and on, and it looks to me that this is an EF 5.0 bug, but according to the connect link this should be fixed, but it doesn't seem to be the case.