Choosing how to migrate a .NET Framework library to .NET 8 (or the future .NET 9, .NET 10, etc.) depends on each application.

Or maybe you don’t even need to migrate. You could add to your existing libraries so they target multiple frameworks.

This is known as “Multi-Targeting:” one package with two (or more) libraries. It’s like having a collector’s edition that contains both a DVD and a Blu-ray disk. It’s convenient but difficult to start and maintain.

You could try an alternative; a method with one library that’s viable in two frameworks.

This is a quick dive into two .NET 8 migration methods: Multi-targeting and what we’ve coined “Bridging,” and how you can implement them to start your NuGet migration!

Multi-Targeting Method

A multi-targeting method for migrating your packages means creating a single NuGet package library that contains both versions of the said library – e.g. the .NET Framework version and the .NET 8 version. By having them in one folder, it falls on Visual Studio which platform to target.

When creating a new application, the developer tells Visual Studio which .NET platform to target. Using a multi-targeted NuGet library, Visual Studio can select the right library from the choices available each time it compiles.

This is a good method because it is efficient. It supports multiple applications on different .NET platforms, keeps libraries in sync, and ultimately saves time.

Multi-targeting is best used when the .NET Framework library and the .NET 8 library are very similar. Yes, the .NET 8 library will have newer, different functionality, but at its core, the codebase remains mostly the same.

To start a multi-targeting migration, you need to configure your project to build multiple times (e.g. as many times as needed for each platform being targeted). Then you would need to build a NuGet package out of all of those assemblies.

It would be like having one NuGet package Kramerica.Data, but within the said package there are two (or more) libraries: Kramerica.Data.FrameworkModels and Kramerica.Data.CoreModels.

Multi-targeting may not be for everyone. There’s a lot of information about it online so consider doing extensive research before diving into it. Likewise, consider the resources that will be needed after multi-targeting has been set up.

Bridge Method

The “Bridge” method is a good alternative to multi-targeting because we consider it a temporary solution. It’s specific to certain .NET Framework versions, but if you’re operating those versions and plan to completely move to .NET 8, Bridge will tide your applications over until a formulated migration plan is ready.

If you’re operating in .NET Framework 4.7.2 or later, your library’s code may be compatible with the deprecated technology NET Standard 2.0. Standard 2.0 was the original Microsoft attempt to unite the .NET platforms. It’s still viable for sharing code between two libraries that don’t include .NET5+ (.NET 5 to .NET 8).

Bridge’s approach means having a single library within a package, instead of two very similar libraries like in multi-targeting. This single library is then “locked” to whatever is available in .NET Framework 4.7.2 (or later).

This method, again, will depend on your situation and isn’t for everyone (like people working exclusively in .NET5+). Because Bridge “locks” a library, you cannot add additional functionality to code like you would be able to in a multi-targeted package.

The benefit of bridging over multi-targeting, however, is the fewer resources needed. Multi-targeting will require writing and maintaining complex code for .NET Framework libraries that will, eventually, be migrated to .NET5+.

The Bridge method simply changes the target of a library (to .NET Standard 2.0) and requires some general troubleshooting/errors that may appear after the target change.

Migrate Your Packages Soon

Ultimately, there isn’t a rush to migrate from .NET Framework. Versions 3.5, 4.6.2 to 4.7, and 4.8 are expected to have long support times (maybe even infinitely in 4.8’s case).

The exception to this however is for those on versions 4.5.2 to 4.6.1, for which support ended April 2022, who will need to consider migrating as soon as possible. 

Migrating is a good idea, however, for those who want all the new features and benefits of .NET 8. The new .NET v.Core series (.NET5+) is also an opportunity to increase your own release cadence and implement a CI/CD process for your NuGet packages.

Migration today isn’t necessary, but getting a head-start with planning will help you in the long run. Deprecation will sneak up on you sooner than you realize. Planning now before operating systems hit end-of-life means your migration will be nearly pain-free.

Did you find this article helpful? Are you looking to migrate from .NET Framework to .NET 8? Sign up for your free guide on how to successfully migrate to .NET 8 and beyond!