Let’s discuss the various flavors of .NET and outline the need and options available for migrating from .NET Framework to .NET Core and eventually .NET 5.

The Flavors of .NET

Current discussions of .NET center around the following 3 buckets of technologies:

• .NET Framework
• .NET Core
• .NET Standard
• .NET 5 (Sometimes referred to as “DotNext”)

Not included in this list are one-off dialects like Xamarin, UWP, and Silverlight which tend to rely on subsets of other versions.

.NET Framework refers to everything from the initial release of .NET to the latest patch of .NET Framework 4.8. All of these are based on the same types of base class libraries.

.NET Core refers to the cross-platform modernized rewrite of the .NET Framework. It is a subset of .NET Framework and doesn’t support some features in .NET Framework. Web Forms is likely the clearest example of an unsupported technology, but other things that rely on Windows-native APIs or are deprecated were not ported over to .NET Core.

.NET Standard refers to class libraries which can be referenced by either .NET Core or .NET Framework projects. This limits the amount of things they can rely on, but offers a good gradual migration strategy for your applications.

.NET 5 is the upcoming next major version of .NET Core. Dropping the “Core” signifier is part of the clear signifier that .NET Framework is entering a long term support phase and .NET Core / .NET 5 will be getting the attention and updates from here on out.

What does this mean for .NET Framework?

My expectation is that .NET Framework will receive only critical maintenance patches and continue to receive LTS support, but will become less and less relevant over time.

This means, that if you want your applications to benefit from future work Microsoft does with its technologies and platforms, you need to be moving to .NET Core / .NET 5.

Migrating to .NET Core / .NET 5

Let’s take a look at a typical .NET Framework web application and discuss some migration strategies for it.

This is a traditional ASP .NET web application using Web Forms and .NET Framework. It consists of pages in web forms format and various classes to represent models and service logic. It also holds application configuration via its web.config file.

In order to migrate off of .NET Framework, we’re going to have to make this web application much smaller in scope in order to achieve our objective.

Introducing a Class Library

Thankfully, we can create a new .NET Standard class library and move non-UI and non-web API classes from our web application into this class library. This significantly shrinks the number of responsibilities our web application project has on its own.

Additionally, by doing this in .NET Standard, we expose any dependency issues in the form of libraries those classes relied on now and can resolve them ahead of moving off of .NET Framework.

Since our class library is in .NET Standard, our .NET Core and .NET 5 projects will be able to reference it and use the logic in it.

Platform Extensions

In the case where you rely on libraries that are native to Windows and are not yet ready to migrate off of them, you can temporarily use Microsoft’s Platform Extensions which were designed to provide environment-specific functionality and make migration a little easier.

Migrating to MVC / Razor

Since .NET Core does not and currently is not planned to support Web Forms, we’ll need to cut over our individual pages to MVC controller classes and Razor views.

Thankfully you can do this gradually as .NET Framework web applications can support both MVC / Razor and Web Forms in the same project.

Note that instead of doing this gradually, you could move directly to .NET Core or .NET 5 and rewrite these pages as Blazor views.

Taking Inspiration from Domain Driven Design

Web apps are large and converting them all typically a fairly massive undertaking. If this is the case in your project, you may want to consider following domain driven design principles and identifying related contexts and silos of pages and classes that could be split out to a new micro-front end.

While this is not something I am qualified to talk significantly amount at this point, pulling multiple smaller .NET Core applications out of a larger .NET Framework application could help you reach your target faster, though introduce challenges as far as authentication and state management goes.

Completing the Migration

Assuming that you have a .NET Framework web application with only razor pages in it, you can take the last step of the migration and port the main web application.

There’s no direct option to migrate a project so what you’ll have to do is create a new .NET Core application and then move your razor views and controllers over to that project.

You will also need to migrate any application-specific configuration options to use the Startup and ConfigureServices methods in .NET Core and the appsettings.json file for state management.

Thankfully, these aspects of .NET Core are very minimal and simple and you should not need a large degree of code to do this.

Once all is ready, you can reference your class libraries and add any relevant NuGet packages, then compile and run your web application.

What about .NET 5?

Since .NET 5 is a natural evolution of .NET Core, the migration path should be very simple once you’re on .NET Core to begin with.

.NET 5 releases at the end of 2020 and preview resources and tutorials will become more readily available as we get closer, but your main battle is going to be getting away from .NET Framework and onto .NET Core. Once on .NET Core, .NET 5 should be just as simple as a version upgrade.

Closing Thoughts

Moving to .NET Core is a massive amount of work in many projects, but we as a community have to face the fact that Microsoft is committed to the future and next versions of the platform and these plans simply do not include Web Forms or even the older .NET Framework technologies.

I love .NET, but it’s time to accept that Framework’s time is waning and it is time to move on to .NET Core and .NET 5. Thankfully, there are migration options available – they just might take a heroic level of work over a long period of time.

Cover Photo by Gareth Davies on Unsplash

The post Migrating to .NET Core and Beyond appeared first on Kill All Defects.