Mission Impossible - Migrating .NET Core 1.x To 2.0

Which came from Microsoft.AspNetCore.Identity.EntityFrameworkCore, now it has been changed and now it comes from Microsoft.AspNetCore.Identity. Not just these, but there are several other objects that got migrated to this namespace, such as IdentityRole. I believe, it was a decision to bring everything under Microsoft ASP.NET Core Identity framework and remove the concept of Entity Framework Core backing up the feature or service, a good decision I would say because why would IdentityRole name depend on EntityFrameworkCore at all, right? So, making this change fixes the problem. That said, now the final problems are that most of the APIs have either been deprecated or have been improved. I am nobody to say anything, in this context because I have not yet run a full test on a number of performance improvements, which ASP.NET Core 2 brings, but of course, there are major solutions and even their verbal explanations give you a notion of the fact that they are improvements to the framework. Same goes for deprecation, we can see why the team wanted to make such changes.

First, let me fix the improvement thing, the improvement thing is the one where your function returned a type, and not it returns a Task<type>.

_signInManager.GetExternalAuthenticationSchemes()...

What I did was I tried to look into the definition of the class, SignInManager and there I figured the definition had changed just a bit,

Thus, just the way we know what happens here is that we apply async/await pattern to get the result in an asynchronous way, so what I did here was,

(await _signInManager.GetExternalAuthenticationSchemesAsync())...

The rest of the code also required some changes, such as the fields AuthenticationScheme required to be changed, as it had been removed. In the default ASP.NET Core code, there is a change in the ViewModel object itself and it accepts IList<AuthenticationDescription> and not the List<AuthenticationDescription>, so that also requires a casting of types. After these changes, the only change required left would be the deprecation.

In most cases, the compilers are configured to consider deprecation as errors instead of warnings. Because, developers are not afraid of warnings, but they are terrified by an error... No matter how major or how small it might be. Thus, in cases where a team has configured deprecation to be considered as an error, the following would solve it. What happens is, that, HttpContext.Authentication is about to go deprecated and would be removed in future updates,

This shows the warning, and would soon show an error and later a build error if not taken seriously. The warning message states clearly, that you should consider the extension methods provided to take care of the signing out process for a user.

This solves that, and the previous line can be commented out if not removed. You should consider updating this everywhere your application was using the code to sign out the user and make the changes based on authentication. After this, the Startup class configuration also requires some updates, and like we have been watching, the app.UseIdentity() has gone deprecated as well, and the recommended alternate to that one is, app.UseAuthentication(). Such other minor changes, but API changing changes, and build breaking changes were implemented in ASP.NET Core 2.0.

In this sample, only this change was detected, your application might have huge scales of changes and they would all be like this one. The purpose was just to give you an idea of what to expect to change and break. Thus, after these changes — and provided I did not have other changes in the application, these were the only one required. Now I can continue to the final change in this post, the Entity Framework Core 2.0.

Entity Framework Core upgrade

In this section, I want to talk about the improvements in Entity Framework Core, as well as the improvements and their effects on other frameworks, such as the case of ASP.NET Core pooling for DbContext objects. I will tell you about that, but again I did not load test any of this so I cannot provide the accurate metrics for any of this now, but soon I will.

Improvements

First let us talk about the improvements, the major one that I like was the ability to add DbContext objects as a pool object, I skipped it from ASP.NET Core section because that section already had a lot to talk about, anyways, what this upgrade states is that you can now add DbContext, as an object to DbContext pool. This way you would be provided with an object which exists in the pool, instead of recreating the object each time a request comes.

This was used to register your DbContext to the DI, and upon each request ASP.NET Core would itself create the object, and then pass it to your constructor. That was fine and worked very excellent, but as you might have guessed for a thousand requests, thousand times object instantiation and Dispose calls unless you configured an alternate way, such as a Singleton or what-so-ever. However, now ASP.NET Core 2 supports a pooling for DbContext, which means it creates the object instance once and reuses the object from pool, and your code becomes,

How much performance boost it might give you, is not mentioned because it depends on several factors and thus stating any of them would be useless.

Also, there was a statement about LIKE clause of SQL to be provided and supported in Entity Framework LINQ queries, something like this would be possible now,

But that could have been done by the older ways of string management in .NET framework, like

The older versions were doing all of this in memory, and hopefully were never converted to SQL LIKE clauses (I might be wrong here), whereas the new EF.Functions.Like(...) gets translated to SQL LIKE clause and the work is done by database server instead of in-memory processing anymore, which would definitely improve the performance.

Problems and breaking changes

Anyways, moving onwards to the changes in Entity Framework Core pipelines, I am going to talk about the problems that you will face while upgrading ASP.NET Core 1.x to ASP.NET Core 2.0. If you have been following up with .NET Core team on GitHub, you will notice that they have mentioned clearly in their "breaking-change" issue label, that there are a lot of changes to the API which would break the build system and to fix them you would have to rewire a lot of things every here and there. For example, the currently open breaking changes in Entity Framework Core repository are, Issues - aspnet/EntityFrameworkCore. Feel free to revisit them to learn more, and to find out what else you were using and which broke during this upgrade.

First and foremost of the changes, which requires being fixed is that now Entity Framework Core requires a default contractor. It was mentioned in one of the issues that Entity Framework Core ignores the DbContextOptions in the constructor because it no longer follows DI chain and expects a Factory pattern to be implemented, too awkward!

#8328 issue

The most noticeable change is that we're going to stop attempting to call Startup.ConfigureServices(). This means that if your DbContext derived type doesn't have a default constructor or isn't in either your startup or target project, you'll need to add an implementation of IDbContextFactory<TContext>.

I could have followed the new design and gone onwards with the flow but my existing application was based on the older version. Most of you would be tempted to create an IDbContextFactory<TContext> class and implement it from there, but what I did was something else, I provided a compile-time and design-time implementation of a default constructor so that my code compiles, the migrations get applied and then I remove that to go back to the same DI service.

Initial state of BlogContext : DbContext

I did not use a sample to demonstrate, but the following was the context which I just came up with,

I was going to apply a migration, because I wanted to add another field, PublishedOn to the post (you understand this is just a demo, right?) and that would require a migration, but since Entity Framework Core does not call the ConfigureServices function, dependency injection will no longer be used and it would complain that you must provide a default constructor. The following was the line,

Now, what I searched and found was that you can add a factory pattern, which returns an instance of the DbContext, on the official documentation pages, there is a sample provided, I captured following code from there,

As you can see, this works. However, this requires that in case of continuous integration toolchain, you must skip the DI and start using this pattern. If you consider it to be a useful method, stick to it, however, I did not like it and so I wanted to apply a quick hack and get my system up and running as it was, and to make sure that Entity Framework Core gets a grip of instance too. So, I made some changes, which are discussed below.

Updating the BlogContext

What I wanted to do, was to maintain the same DI chain, and to make sure that my Entity Framework Core thing works, I just provided a default constructor and by overriding the OnConfiguring constructor added the same service of adding migrations through Add-Migration and Update-Database command. Following was my solution,

Before you start to bash me up, I want to state that you do not need to add this code here, if you are using version control this code can be removed without breaking anything because it is not required by application. Let me enlist the points, most of you would not get the point and start to bash,

1. The default constructor and overriding the function is not required by ASP.NET Core 2.0.
2. They can be removed as soon as you have applied migrations.
   1. Same is the case for your connection strings, they are not needed in the code.
   2. You can still follow the jsonway of storing settings, or consider other means of storing connection string easily (such as Microsoft Azure App Service default values, for connection strings etc.), because on the runtime it is your Startup class maintaining everything.
3. The problem was just with Entity Framework Core not being able to capture this instance from Startup class and in ASP.NET Core 1.x only.
4. In the ASP.NET Core 2.0, you can still use the same code and you are not required to provide a default constructor, because Entity Framework Core team updated their toolchains and manage how the services are created in pipeline and act as needed.

Which brings us back, to the claim that in most cases you should consider migrating the pipeline of functions to ASP.NET Core 2.0 as well, nonetheless, if you are so much backed up with ASP.NET Core 1.x then there is less hope for you, let’s hope soon .NET Core team publishes a script to upgrade .NET Core 1.x apps to .NET Core 2 applications, hierarchically moving down to ASP.NET Core and Entity Framework Core to provide a wonderful experience for users.

Final words

The upgrade suggestions which I had found are shared in this post, and hopefully, if you ever want to apply these changes this post will help you, I will keep an eye on other problems and issues related to .NET Core migration, I will share them here. In case you find a few areas which I missed to cover, please do let me know and the changes which I have told here are opinions, these may not be the best approaches — such as that default constructor thing in DbContext.

If your application still does not work or does not build itself, follow the steps,

1. Try to Google for the problem, chances are that you will find a discussion thread on GitHub.
2. Apply those changes and see what happens.
3. Comment here and I will try finding the solution as well and post it here.
4. If nothing works out, you may be required to create a new project with ASP.NET Core 2.0 template and migrate everything manually, unless they come up with a script for migration.

Pardon me for a while, I will present a separate test-based alternative soon, which will talk about how much of improvements benefit you get from these changes. ASP.NET Core load testing, Entity Framework Core SQL profiler and much more can be covered but in this post my focus was to make sure that you can know how to solve these common problems, as soon as possible. I understand this because I also had to undergo this.