Hi,

You don't use one over the other. We use an initializable module to run EF code first migrations automatically. You can follow all EF migrations guides to set everything up, but instead of doing the migrations in Application_Start in global, you do them in an initializable module.

Hi Johan,

I see, from the documentation it hints that it's one or the other, thanks for the clarification.

I'm having a few issues setting this up and it's difficult to know whether it's worked or not. I'm using VS 2015 and I see from the publish dialog on the Settings screen there is an option to 'Update database' and a link to 'Configure database updates'. Clicking the link provides the ability to add a SQL script, do you know if this will work? All my changes are already scripted and this seems like a better option as I can control what database changes get deployed easier (although I guess this could cause issues as it gets deployed through the DXC environments?).

Thanks,

Mark

Hi,

I can't tell you really what the best approach is. But I prefer to have the migrations in my code, with a fluent API. This is what we have in our module:

using System.Data.Entity;
using EPiServer.Framework;
using EPiServer.Framework.Initialization;

[ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
public class MigrationInitialization : IInitializableModule
{
    public void Initialize(InitializationEngine context)
    {
        Database.SetInitializer(new MigrateDatabaseToLatestVersion<TheDbContextHere, TheDbMigrationConfigurationHere>());
    }

    public void Uninitialize(InitializationEngine context)
    {
        // Nothing
    }
}

This will make sure appropriate migrations are executed on startup. TheDbMigrationConfigurationHere class will be generated when you enable code-first migrations for your DB context.

I would say this is more an Entity Framework specific question and you will probably find or get better answers at Stack Overflow.

Hi Johan,

Thanks for the update and your code sample.

At the moment I don't know if it's not working as a result of the EF setup or my initialization module (code below). I've checked lots of EF samples and as far as I can tell mine is set up as expected.

    [InitializableModule]
    [ModuleDependency(typeof(EPiServer.Web.InitializationModule))]
    public class DatabaseInitializationModule : IInitializableModule
    {
        public void Initialize(InitializationEngine context)
        {
	    //DBContext = partial class in separate project that inherits from DbContext defines DbSet of tables and has OnModelCreating method
	    //MigrationConfiguration = public class in same project as context file in Migrations folder has empty Seed method
	    Database.SetInitializer(new MigrateDatabaseToLatestVersion<DBContext, MigrationConfiguration>());
        }

        public void Uninitialize(InitializationEngine context)
        {
            //Add uninitialization logic
        }
    }

Is there any way to troubleshoot or debug the initialization module to see if it's being hit on delpyment to DXC?

Thanks,

Mark

Migrations are tricky. Especially the "initial create" one. I'm pretty sure that your issues are in the EF setup. You can debug locally, just delete the MigrationsHistory table and all tabels you have in your context. Then you should get the same errors locally as in Azure when no migrations have been applied.

Presumably I'll need to run the Update-Database command from the NuGet console against my class library to test this locally once I've deleted the tables from the database.

No, that's the tricky part. You want your migrations to do that for you, since you don't want to do that manually in Azure.

Ok, so I just need to run the site, the initialization module should kick in and then hopefully I should see an error. Is there any way to debug this to see what's going on? Will adding some break points to my DbContext file work?

You can add a breakpoint in the initialization module. But you need to restart the application for it to kick in (since it's only running once on application startup).

I've never debugged the migrations step, so sorry can't help you there.