Migrating to Identity Core 2.0

Migration to ASP.NET Core Identity 2.0 is an important part of migration to ASP.NET Core 2.0 is. In our case of migration, we had to migrate from “AspNet Full Framework” to “AspNet Core 2.0”. All entities (models) in our case have to inherit from a specific base class and implement a specific interface. So adapting Identity to this, needs special considerations.

IdentityUser generic signature

First shocking change I saw, was IdentityUser. Former one allowed to introduce all other identity entities via its generic signature. Like this:

But Identity Core has changed it to:

It was easy to handle but in first glance it shocked me! This signature is not needed any more. Introducing it in just IdentityDbContext is enough:

New entities and field type changes

Identity Core 2.0 has introduced 2 new entities: RoleClaim and UserToken. Also date time columns in database tables have been changed to datetime2(7). Other changes also happened. For example, Role has 2 new fields, ConcurrencyStamp and NormalizedName.


Generating JWT seems to be easier than .Net Framework and OWIN. Formerly we have been using:

While a sample code for generating JWT in ASP.NET Core 2.0 is like this code (inspired from here):

BTW it seems that JWT consumption has not been changed a lot. In .Net Framework/OWIN we had UseJwtBearerAuthentication and in ASP.NET Core 2 we have AddJwtBearer. They both accept some configurations.

See a sample generated JWT using ASP.NET Core 2.0 below.


EF Core automatic migration

In our way toward migrating an ASP.NET full framework application to ASP.NET Core 2.0 we encountered a significant change in EF Core 2.0 in comparison with EF 6.x.


EF 6.x

In EF 6.x we were tightly relying on automatic migrations in deployment operations. We never created or added a migration to the code-base. Instead we had turned on automatic migration and allowed data loss. So when new versions of the project were deployed on the server, all necessary changes on the database were done behind the scenes automatically.

I know that enabling automatic migration on a production server is not a good idea. But it was a constraint forced by our deployment team.

Entity Framework Core
Entity Framework Core

EF Core

Automatic migration has been removed from EF Core. This feature is not present in EF Core 2.0. There is no plan to add this feature to EF. Microsoft thinks it benefits is less than its drawbacks.

There are 2 methods in EF Core 2.0 related to migration. Database.Migrate() and Database.EnsureCreated(). Neither of them are a complete migration.

Migrate() does not add or create a migration. It only checks if any not-applied migrations exists or not. If yes, then updates the database based on them.

EnsureCreated() creates the database based on the models in the project. But it does not do this in the migration way. Actually no migrations are needed by this method. Disadvantage of this method is that a database created by it, can not be updated in future by any migrations. Indeed this method is added to EF to help people create projects fast in MVP style.


At the end, we decided to not having automatic migrations as EF 6.x. Everyone that creates a model is responsible to create migrations too. And never call EF command in the production server to update the database. Instead call the Migrate() method on each startup to take the database to the latest available migration.

A sample code would be like this:


Sample code inspired from here.

Migrating to ASP.NET Core 2.0

It is early September 2017. ASP.NET Core 2.0 has been out for a week or so. My computer has it. There is a project that has been started in early days of ASP.NET Core 1.0 beta days. That start day we did not used ASP.NET Core because of its beta nature. Instead we went with ASP.NET and OWIN.

Today that ASP.NET Core is mature enough, we are going to upgrade our project to ASP.NET Core 2.0 on .Net Core. Hopefully we can soon develop and run the project in Ubuntu in addition to Windows!

ASP.NET Core 2.0
ASP.NET Core 2.0

Personally I have been working with Visual Studio Code for last year so I am comfortable with it. But as other teammates are using Visual Studio 2017 so I start my work from Visual Studio 2017. In future I can use Visual Studio Code in non fundamental code sessions.

Target project is a solution consisted of some projects. Each project is responsible for a set of functionalities. Project Domain for basic entities, enums, dtos, etc. Core mainly for business logic and Web for technologies related to web. Domain project is in lowest level, so I started with it.

Name-space and Nuget changes aside I encountered my first challenge while porting a class that was inheriting IdentityUser. Old identity can accept a row of generic parameters while Identity Core has changed them significantly.

Old Identity User
Old Identity User
Identity Core User
Identity Core User

This story is going to be continued…