Migrating from .NET Framework to .NET Core

Migrating from .NET Framework to .NET Core

Over the course of several years, I’ve been slowly migrating a 5-year-old system built on top of .NET Framework (v4.8). In this blog series, I’m going to describe each step of the migration, as there were many, in order to get the system running entirely on .NET Core. This is series intended as a guide for Migrating from .NET Framework to .NET Core.

This wasn’t a “big bag” migration, but rather a series of steps that were taking over the course of years. That’s not to say your migration will take as long.

System Background

In order to get a sense of the undertaking and for hopefully relating it to the system you might be migrating, it’s worth me describing my system at a high level.

The system is a modular monolith. It’s comprised of multiple projects that each contain specific business functionality. Each project is a boundary for that functionality. There are two main entry points, a web application and a worker.

Web Application

The primary interface is an HTTP API that is accessed via a web/typescript frontend, mobile app, and C# clients. This interface was originally developed using the Katana (OWIN). Primarily all HTTP APIs were developed using Nancy, however, there was a sprinkled amount of ASP.NET WebAPI and OData.

This project was self hosted using Katana’s HTTPListener in a console application. It was not hosted with IIS.

This is project is important to note because it did give us a head start. Project Katana is a precursor to ASP.NET Core before I really knew it. There are many similarities in how you configure your web application such as the Startup, configuring Middleware, etc.

Worker / Queue Processing

The other part of the system is processing messages from a queue in a console application. These messages are generally created by the web application, however, this application does publish it’s own jobs to the queue.

Ultimately this application is just another entry point/interface to the application. They are the only two executables in the system. They both reference the exact same projects that contain the actual business functionality of the system. Both the worker and web application are thin projects that only contain code to set up for their respected interfaces, HTTP and message queues.


This series will cover the following topics in migrating this system. Again, some might be applicable to you, some may not. Hopefully, some of these topics will help you in migrating from .NET Framework to .NET Core.


Migrate from Katana (OWIN) to ASP.NET Core. This is actually pretty straight forward in terms of moving custom middleware over or if you’re coming from Web API.

Base Class Library

What types you may be used in the .NET Framework Base Class Library that do not exist in the .NET Core Base Class Library. How you can find these missing types via the Compatability Analyzer and if there are replacements. The biggest hurdle here is generally any type residing under System.Web

3rd Party Dependencies

There are two aspects to 3rd party dependencies via NuGet for migration:

  • .NET Core and/or .NET Standard Support
  • API Surface

The last point is the tricky one. Just because you’re using a NuGet Package on .NET Framework, that has the same version that targets .NET Core or .NET Standard does not mean that package, even though its the same version, will have the exact same APIs available.

Entity Framework (Core)

One large dependency for most projects is Entity Framework. Migrating to Entity Framework Core might not be feasible, but there are options for running your existing Entity Framework 6.x code on .NET Core.

Migrating from .NET Framework to .NET Core

Follow along on this blog series as I cover the above discussion points and how I managed to Migrate. If you’ve done a migration, please let me know in the comments below about any pain points you had as I may have also had them but forgot to mention them here.

Blog Post Series

Related Links

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Queuing Background Jobs with Coravel


In one of my live streams on my YouTube Channel, I took a look at using Coravel to refactor some code that was sending out an email. Emailing is a good example of something that can be created as a background job that frees up your web application to return a result quicker to the client.


Coravel gives you a zero-configuration queue that runs in-memory to offload long-winded tasks to the background instead of making your users wait for their HTTP request to finish!

It’s pretty easy to get started to run background jobs with Coravel in your ASP.NET Core apps, or really any app that is using Microsoft.Extensions.DependencyInjection and IServiceCollection. Simply call AddQueue() from ConfigureServices()

Background Job

In my live stream, I refactored the code used for sending a verification email to use Coravel to enqueue a background job to be handled in a separate thread. Here’s what I did to make that happen.

The first step is to create a class that implements IInvocable and in my use case also implements IInvocableWithPayload<T>, which also allows us to pass data (eg, parameters) to our background job.

This class will be constructed and invoked when our background job is enqueued. Because we’re using the MS DI, you are free to inject dependencies via the constructor, so as long as they are registered.

What that looks like in its simplistic form:

Now to call the new invocable as a background job, you will need to inject the IQueue into your Controller (or any class). From there you can call IQueue.QueueInvocableWithPayload

To tie things all up, you need to register your invocable in your ConfigureServices so Coravel can use the MS DI to create a new instance of it.

More Coravel

Coravel actually does a lot more than just queueing background jobs. Task Scheduling, Caching, Event Broadcasting, and Emailing. Check out the project on GitHub.


Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #67: Cert Expiration Check, Should I use MicroServices? StackOverflow Survey, gRPC-Web

Here are the things that caught my eye recently in .NET.  I’d love to hear what you found most interesting this week.  Let me know in the comments or on Twitter.

Certificate Expiration Check

I thought this was a pretty cool idea and an easy way to keep track of expiring certs.

Link: https://github.com/ardalis/CertExpirationCheck

Should I Use A Microservices Architecture?

Are you considering adopting a microservices architecture? Won’t it fix all your problems? Join me for a look into the realities of microservices!

Link: https://www.jamesmichaelhickey.com/microservices-architecture/

2020 Stack Overflow Developer Survey

Thank you for taking the 2020 Stack Overflow Developer Survey, the largest and most comprehensive survey of software developers (and anyone else who codes!) on Earth. 

Link: https://stackoverflow.az1.qualtrics.com/jfe/form/SV_eL0mFVwuo7KWeXP

A new experiment: Call .NET gRPC services from the browser with gRPC-Web

I’m excited to announce experimental support for gRPC-Web with .NET. gRPC-Web allows gRPC to be called from browser-based apps like JavaScript SPAs or Blazor WebAssembly apps.

gRPC-Web for .NET promises to bring many of gRPC’s great features to browser apps:

Strongly-typed code-generated clients
Compact Protobuf messages
Server streaming

Link: https://devblogs.microsoft.com/aspnet/grpc-web-experiment/

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.