Setting up Migrations for Episerver AspNetIdentity

Episerver has been supporting Microsoft’s ASP.NET Identity platform for some time now. This brings many benefits over the older membership provider. Some of these benefits include decoupled design, asynchronous support, and the mapping of external logins to local accounts. Episerver provides a NuGet package EPiServer.CMS.UI.AspNetIdentity along with some documentation on Episerver World to get started using the identity framework.

There is, however, one missing component to the documentation that I’ve not seen discussed: migrations.

Migrations allow developers to modify the user model class to add or remove custom properties such as birth date or membership level. Since Identity is built with Entity Framework, a developer may think adding migrations is as simple as executing "enable-migrations" from the package manager console in Visual Studio; however there is one catch here. The DbContext class exists in the EPiServer.CMS.UI.AspNetIdentity NuGet package, and it will result in an error (No context type was found in the assembly ‘NameofProject’).

The simple solution to this error is manually adding a Migrations/Configuration.cs class with the following code: 

namespace AlloyIdentity.Migrations
{
    // note: use package manager console to Add-Migration to pickup user model changes

   internal sealed class Configuration :
        DbMigrationsConfiguration<ApplicationDbContext>
    {
        public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;

           // important: context key must match the default key,
            // if a custom user class was used replace ApplicationUser with it
            ContextKey = typeof(ApplicationDbContext).ToString();
        }
    }
}

The important part here is setting the ContextKey correctly to match the key in the __MigrationHistory table. CustomApplicationUser is a class that derives from the delivered ApplicationUser class provided as noted below:

namespace AlloyIdentity.Models
{
    public class CustomApplicationUser : ApplicationUser
    {
        public DateTime Birthday { get; set; }

       public int MembershipLevel { get; set; }
    }
}

The CustomApplicationUser model name and properties can be modified as needed and will vary from project to project.
The final steps to setting up migrations is creating an initialization module to run the migration on Episerver startup:

namespace AlloyIdentity.Business.Initialization
{
    /// 
    /// Startup module to run migration configuration on site start
    /// 
    [ModuleDependency]
    public class InitDb : IInitializableModule
    {
        public void Initialize(InitializationEngine context)
        {
            Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>());
        }

       public void Uninitialize(InitializationEngine context) { }
    }
}

Also, it involves changing references in Startup.cs from ApplicationUser to CustomApplicationUser (or name of the user model class that derives from Applicationuser).

Now, with the Migrations/Configuration.cs file in place, the package manager console command add-migration can be used to update changes to the user model which will modify the user tables during the web site startup.

In a future article, I’ll show how we migrated an existing site from the older membership to the identity framework.

Happy migrations!

Do you have questions? Make sure to leave a note in the comments below or over social media. Sign up to get weekly emailed alerts when this type of content comes through our blog.