Options

SQL Change Automation with EF Core code first database/entities

I have created a set of entity classes using EF Core and going to create a code first database.  I have used SQL Change automation in the past with a database first architecture but what is the best way of using sql change automation with a code first database.  

I am using VS2019.  Do I need to use the standard VS migration function to update my local dev database with code first changes and then use sql change automation to generate the scripts for the target production environments or can i use SQL Change Automation to link my code first entities to the local dev database and also my production enviroments

Answers

  • Options
    Alex BAlex B Posts: 1,132 Diamond 4
    Hi @brookal,

    There used to be more on EF CodeFirst in version 3, but from version 4.1.20006 release notes:

    SCA-2638 - We no longer write an EntityFramework code-first migration scripts to the migration scripts folder when the Package Manager command is run within Visual Studio. This behaviour was always branded as experimental and has never been supported in Visual Studio 2019. We recommend creating SQL Change Automation scripts manually and copying the entity framework code inside (either setting the TransactionHandling attribute to Custom or manually removing the generated transaction handling code) or generating migrations directly through SQL Change Automation.


    So that the advice!

    Kind regards,
    Alex
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
  • Options
    brookalbrookal Posts: 14 New member
    Would it be possible to use the standard VS2019 migrations to create a local dev database being monitoring by the DLM dashboard as a safety check.  

    After that, can I then create a deployment project to create/deploy the change scripts to my integration and production databases.
  • Options
    Alex BAlex B Posts: 1,132 Diamond 4
    I'm not quite sure what you mean by the "standard VS2019 migrations" or generally what you are trying to have your workflow be.

    If you are using SCA in VS, you would have migrations being written there (based on the EF recommendation above, you would either copy the EF migrations each into their own migrations or apply the changes to your dev database and then use SCA to import the migrations).

    You then use the SCA in VS project as the source of PowerShell components, whether that is using the cmdlets specifically or using addons for some of the various build/deployment tools available. 
    Product Support Engineer | Redgate Software

    Have you visited our Help Center?
Sign In or Register to comment.