Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
In the quest to migrate to .NET Core, the first step at the time (a couple of years ago) was to start migrating to ASP.NET Core from using Katana (Owin). This seemed like a logical first step as ASP.NET Core 2.x could run on .NET Framework as well as .NET Core. Ultimately this was a good first step in our migration.
ASP.NET Core 3.x is only supported on .NET Core 3.0 because it targets netstandard2.1.
.NET Framework only supports netstandard2.0 and will never support netstandard2.1
This makes it much more challenging to migrate because my recommendation is to get your application 100% compatible with netstandard2.0. If you do this, then you’ll be compatible with .NET Core 2.1.
Once you’re compatible with .NET Core 2.1 you can then can start running your applications on .NET Core 2.1 and from there, you can then migrate to .NET Core 3.x.
Migrating from .NET Framework to .NET Core
This blog post is in a series about migrating from .NET Framework to .NET Core.
- Migrating from .NET Framework to .NET Core Overview
- .NET Portability Analyzer
- Multi-Targeted NuGet Package Gotchas!
- NuGet Package Alternatives when Migrating to .NET Core
- Mission Complete
Katana (OWIN)
Our web application was using the Katana Project and was self hosted using HttpListener. It was not using IIS.
This made our migration much simpler in some aspects because Katana really feels like a precursor to ASP.NET Core. Much of the same concepts exists such as the Startup and Middleware.
I’ve previously blogged about Migrating from Katana to ASP.NET Core. The general gist for migration is to implement any custom middleware you have with Katana over to ASP.NET Core. It’s really straight forward to do so and should feel natural. Most of the types are even named the same or very close to the same.
Web API
If you’re using ASP.NET Web API my biggest recommendation is to use the Compatibility Shim package.
This will save a bit of work as it adds functionality to ASP.NET Core to that was available in Web API. For example, it adds an ApiController type so you don’t need to update all your controllers to reflect the new ASP.NET Core Controller type.
Check out the official docs on the compatibility shim and what it provides and how to use it.
MVC
I don’t have much experience migrating MVC, however, I have used both ASP.NET MVC 5 and ASP.NET Core MVC and it doesn’t feel all that different. All the same, types (by name) exist such as Controller, ActionResult, etc.
Razor is still the same and so are layout files and the _ViewStart.cshtml.
Just like migrating Web API, you will need to create an ASP.NET Core application with the correct Startup class, and add/configure the MVC.
Check out the official docs on migrating from ASP.NET MVC
Migrating to ASP.NET Core Recommendation
My recommendation is to migrate to ASP.NET Core 2.1 and run it on .NET Framework 4.8.
The long term goal is to be running the latest ASP.NET Core on .NET Core. However, in order to migrate to ASP.NET Core, you want to be able to still run your application, which requires .NET Framework.
Do not worry about all your other dependencies yet, we will cover that in another post.