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

Follow @CodeOpinion on Twitter

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #69: ASP.NET Core Urls & Ports, Tye, Orleans, and Diagnostics

After a bit of a break, the .NET Roundups are back! This week, it’s almost as if Andrew Lock was working on the exact same I was as he had two posts back to back that solved two issues I was having. Incredible timing and as always great content from Andrew.

Follow @CodeOpinion on Twitter

5 ways to set the URLs for an ASP.NET Core app

In this post I show 5 different ways to change which URLs your app listens on. We’ll look at each of these options in more detail below.

Link: https://andrewlock.net/5-ways-to-set-the-urls-for-an-aspnetcore-app/

How to automatically choose a free port in ASP.NET Core 3.0

In this post I show one way to resolve the problem by randomising the ports ASP.NET Core uses when it starts the application. I’ll also show how you can work out which port the application has selected from inside your app.

Link: https://andrewlock.net/how-to-automatically-choose-a-free-port-in-asp-net-core/

Service and Container Orchestration for .NET with Tye

Tye helps .NET Core developers build applications that are a collection of services and containers. On your local machine, Tye runs your .NET services, any containers you need, and a dashboard you can use to inspect this environment. Tye can then deploy your services and containers to your Kubernetes cluster.

Link: https://staffordwilliams.com/blog/2020/04/07/service-and-container-orchestration-for-dotnet-with-tye/

Project Orleans and the distributed database future with Dr. Philip Bernstein

Forty years ago, database research was an “exotic” field and, because of its business data processing reputation, was not considered intellectually interesting in academic circles. But that didn’t deter Dr. Philip Bernstein, now a Distinguished Scientist in MSR’s Data Management, Exploration and Mining group, and a pioneer in the field.

Today, Dr. Bernstein talks about his pioneering work in databases over the years and tells us all about Project Orleans, a distributed systems programming framework that makes life easier for programmers who aren’t distributed systems experts. He also talks about the future of database systems in a cloud scale world, and reveals where he finds his research sweet spot along the academic industrial spectrum.

Link: https://www.microsoft.com/en-us/research/blog/project-orleans-and-the-distributed-database-future-with-dr-philip-bernstein/

Introducing the Diagnostics Client Library for .NET Core

In this episode, we’re joined by Software Engineer Sung Yoon Whang from the .NET Runtime team. He’s here to talk to us about the diagnostics client .NET Core. Using the library, you can communicate with CoreCLR to gather diagnostics dumps from your running application.

Link: https://channel9.msdn.com/Shows/On-NET/Introducing-the-Diagnostics-Client-Library-for-NET-Core?WT.mc_id=ondotnet-twitter-cephilli

Follow @CodeOpinion on Twitter

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.

Roundup #58: Orleans 3.0, Snitch, What’s Your Problem? Next 5 years of ASP.NET Core

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.

Follow @CodeOpinion on Twitter

Introducing Orleans 3.0

We are excited to announce the Orleans 3.0 release. A great number of improvements and fixes went in, as well as several new features, since Orleans 2.0. These changes were driven by the experience of many people running Orleans-based applications in production in a wide range of scenarios and environments, and by the ingenuity and passion of the global Orleans community that always strives to make the codebase better, faster, and more flexible. A BIG Thank You to all who contributed to this release in various ways!

I was happy to see the generic host for co-hosting with something like ASP.NET Core. I’ve blogged Co-Hosting Orleans and ASP.NET Core which this about this feature.

Link: https://devblogs.microsoft.com/dotnet/orleans-3-0/

Snitch

A tool that helps you find transitive package references that can be removed.

> snitch Foo.csproj --tfm net462

Building Foo (net462)...

Building Bar (netstandard2.0)...

Building Baz (netstandard2.0)...

The following packages can be removed:

Autofac (ref by Baz)

Newtonsoft.Json (ref by Bar)

The following packages might be removed:

Castle.Core (ref by Baz) 4.4.0 <- 4.3.1 (Baz)

Link: https://github.com/spectresystems/snitch

What’s Your Problem? – Asbjørn Ulsberg

A talk given by Asbjørn Ulsberg from PayEx at the 2019 Platform Summit in Stockholm.

An API isn’t stronger than its weakest link and what’s often ignored in the ongoing maintenance and development of an API is the constant effort required to provide great self-servicable error messages. What this means is that without great, user-friendly error messages, your API is not going to be great.

Just think about your first interaction with an API. How many failing requests have you sent before you have dug yourself through swathes of error messages and documentation to get to that one penultimate successful request making your heart sing and fists shaking in the air?

Great error messages make them not feel like errors, but like friendly guidance towards a working request. They should be detailed enough to let the developer fix whatever problem there is themselves, like a dialogue between a customer and a support technician.

This talk will give you ideas of how to handle errors and exceptions that occur in your application, be it with the incoming request, database failures or errors received from a 3rd party and how to serialize them into user friendly and actionable problem messages.

Link: https://www.youtube.com/watch?v=ZWIUn5BHDBc

The next 5 years of ASP.NET Core – Ryan Nowak

Join Ryan Nowak on a tour of ASP.NET Core’s evolution from “Project K” to present day and look forward to a few possible futures. We’ll discuss technical design details of how the ASP.NET Core stack is changing from bottom (hosting and startup), through the server, middleware pipeline, and up to high-level frameworks like MVC and Blazor.

This is a technical deep-dive talk, and will explore possible design directions of .NET 5 and future releases.

Link: https://www.youtube.com/watch?v=7dJBmV_psW0

Follow @CodeOpinion on Twitter

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.