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.

Migration

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.

ASP.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.

Roundup #52: .NET Core and systemd, System.Threading.Channels, screencastR, Configuration Pitfalls

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.

.NET Core and systemd

In preview7 a new package was added to the Microsoft.Extensions set of packages that enables integration with systemd. For the Windows focused, systemd allows similar functionality to Windows Services, there is a post on how to do what we discuss here for Windows Services in this post. This work was contributed by Tom Deseyn from Red Hat. In this post we will create a .NET Core app that runs as a systemd service. The integration makes systemd aware when the application has started/is stopping, and configures logs to be sent in a way that journald (the logging system of systemd) understands log priorities.

Link: https://devblogs.microsoft.com/dotnet/net-core-and-systemd/

An Introduction to System.Threading.Channels

I’ve recently begun making use of a relatively new (well, it’s a little over a year old at the time of writing) feature called “Channels”. The current version number is 4.5.0 (with a 4.6.0 preview also available as pre-release) which makes it sound like it’s been around for a lot longer, but in fact, 4.5.0 was the first stable release of this package!

In this post, I want to provide a short introduction to this feature, which I will hopefully build upon in later posts with some real-world scenarios explaining how and where I have successfully applied it.

Link: https://www.stevejgordon.co.uk/an-introduction-to-system-threading-channels

screencastR – Simple screen sharing app using SignalR streaming

In this article, we will see how to create simple screen sharing app using signalR streaming. SignalR supports both server to client and client to server streaming. In my previous article , I have done server to client streaming with ChannelReader and ChannelWriter for streaming support. This may look very complex to implement asynchronous streaming just like writing the asynchronous method without async and await keyword. IAsyncEnumerable is the latest addition to .Net Core 3.0 and C# 8 feature for asynchronous streaming. It is now super easy to implement asynchronous streaming with few lines of clean code. In this example, we will use client to server streaming to stream the desktop content to all the connected remote client viewers using signalR stream with the support of IAsyncEnumerable API.

Link: https://jeevasubburaj.com/2019/08/13/screencastr-simple-screensharing-app-using-signalr-streaming/

Avoiding ASP.Net Core Configuration Pitfalls With Array Values

ASP.NET Core continues to improve on the legacy of the .NET Framework. Our team is impressed with its performance and excited about future possibilities, but change is seldom a smooth transition. In this post, I’ll explain a pitfall you may run into using the newest configuration model in .NET Core and options to mitigate the issue.

Link: https://rimdev.io/avoiding-aspnet-core-configuration-pitfalls-with-array-values/

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #35: Startup Hooks, HttpMaster, 7+M req/sec, Pre-Building Services, DockerComposeFixture

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

[C#] Have some fun with .net core startup hooks

One feature of .net core 2.2 that didn’t catch my mind immediately is the startup hooks. Put simply, this is a way to register globally a method in an assembly that will be executed whenever a .net core application is started. This unlocks a whole range of scenarios, from injecting a profiler to tweaking a static context in a given environment.

Link: https://medium.com/@kevingosse/c-have-some-fun-with-net-core-startup-hooks-498b9ad001e1

HttpMaster 4.3

Link: https://www.httpmaster.net/download

ASP.NET Core: Saturating 10GbE at 7+ million request/s

Looking at the latest run from the TechEmpower Benchmarks continuous results ASP.NET 2.2 is the 3rd fastest webserver (0.046% off the top spot); able to respond to 7 Million HTTP request per second

Link: https://www.ageofascent.com/2019/02/04/asp-net-core-saturating-10gbe-at-7-million-requests-per-second/

Reducing initial request latency by pre-building services in a startup task in ASP.NET Core

This post follows on somewhat from my recent posts on running async startup tasks in ASP.NET Core. Rather than discuss a general approach to running startup tasks, this post discusses an example of a startup task that was suggested by Ruben Bartelink. It describes an interesting way to try to reduce the latencies seen by apps when they’ve just started, by pre-building all the singletons registered with the DI container.

Link: https://andrewlock.net/reducing-latency-by-pre-building-singletons-in-asp-net-core/

DockerComposeFixture

I happen to catch this twitter thread and noticed Khalid posted a link to this GitHub repo.

A XUnit fixture that allows you to spin up docker compose files and then run tests against them.

Link: https://github.com/devjoes/DockerComposeFixture

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.