Sponsorship is available! If you’d like to sponsor CodeOpinion.com and have your product or service advertised exclusively (no AdSense) on every post, contact me.
It’s been over 5 years since I started a greenfield project that initially was developed using Katana/Owin with ASP.NET Web API. Over the past 3 years, since .NET Core 2.0 was released and .NET Standard 2.0 was defined, I’ve been slowly chipping away at migrating to .NET Core. It’s been a long road but we’re now fully migrated and running in production with ASP.NET Core on .NET Core 3.1.
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
- Migrating to ASP.NET Core
- .NET Portability Analyzer
- Multi-Targeted NuGet Package Gotchas!
- NuGet Package Alternatives when Migrating to .NET Core
To give some sense of scale, our application consist of two primary entry points.
The first is an HTTP API that started out as a shelf hosted (not using IIS) Owin/Kata using ASP.NET WebAPI. Over time that morphed into using Nancy. During the migration, it ultimately moved to ASP.NET Core using the OWIN Middleware to still use Nancy.
The second entry point is a worker process that processes messages from a message broker. This is primarily for handling events and fire-and-forget commands. This has always been a console app.
To give a sense of scale, I ran NDepend over our solution to get lines of code metric, just to give some idea of the size.
Journey: Migrating to .NET Core
I’ve given a full experience report on my YouTube channel. This covers pretty much everything I’ve done along with the process of getting our app running under .NET Core in production.
Questions or Feedback
If you’re thinking of doing a migration and have any questions, let me know in the YouTube comments, in the comments on this blog or on Twitter. I’d be glad to help if possible.
If you’ve done a migration and would like to share some tips, get in touch with me!