9 Comments

  1. hlattanzio

    Thank you for putting this all together.

    I’ve followed your configurations in order to update the build to generate the migrations script. The csproj file contains and I can see that it is restored as part of the Restore step of the build, however, when the command line task runs in order to run the dotnet ef command, I continue to get this error:

    No executable found matching command “dotnet-ef”

    Any suggestions of what else could be missing?

    • hlattanzio

      Ok, I’ve answered my own question, however, it might be worth noting in your article.

      The project I needed to run the migrations in was a sub-directory, so I had to modify the Working Folder in the Advanced section of the Command line step, such that I wasn’t at the root of $(Build.SourcesDirectory).

      Thanks

  2. Joe

    Awesome blog – I have a few questions though.

    If you go with the option of letting the build pipeline run the migration scripts won’t you be faced with a couple of problems?

    1. Will the ‘ef migrations script’ command generate scripts for ALL migrations all of the time or will it just do the latest migration
    2. When you execute the scripts in this fashion, does it invalidate the fact we’ve recorded which scripts have been run previously and therefore you potentially risk executing old migrations?

    • abel

      Hi Joe
      1. The ef migrations script command should only generate you the scripts that you will need to go from one version to another
      2. It will only generate the scripts you need so you won’t be running scripts multiple times

  3. Behrad Izadi

    a quick one:
    when ef generates migration Script since it has no idea about SQL azure connection string at the time of generating the script how possibly know about changes need of production database.

    I assume we have local database connection string when committing our code

    thanks

    • abel

      When using EFCore, it creates a version table in your DB and keeps track which version the DB is at (or which migrations have been run). When running the script, it will only run the correct sequence of migration scripts to get you to whatever version your versions table says you are on, to the most current one.

  4. Hello Abel, great presentations on the possibilities of the Azure DevOps projects.

    I’ve been running into some of the same problems expressed above but using .net EntityFramework 6.2.0 (not Core).

    For one, it looks like context.Database doesn’t have the Migrate method (though I set AutomaticMigrationsEnabled = true; in the Migrations.Configuration method.) Still, it looks like this easy approach isn’t working on the non-Core version even in my local dev environment… still have to run Update-Database.

    Also, it would be great to have some walkthrough’s on adding a non-LocalDb database in the DevOps project Release. Looks pretty clear to me at the moment that the basic SampleWebApp doesn’t support LocalDB. I’m hoping the addition of database support will be added soon to the basic templates.

    Let me know if there are any good examples of this already. I’ll be researching the current VSTS course offerings.

    thanks

    • abel

      Hi Charles,

      I’ll write up a blog post for you on using EF (Not EF core). Quick answer, you should be able to do all the same things I talked about in this blog. The exact call is a little different but the same thing exists. I’ve made a note to make sure I talk about connecting to non local db’s. Stay tuned, should have something up in about 2 weeks.

Leave a Reply to Behrad Izadi Cancel reply

Your email address will not be published. Required fields are marked *