Two Migrating Methods for .NET Framework to .NET 6
Choosing how to migrate a .NET Framework library to .NET 6 (or the future .NET 7, .NET 8, 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 BluRay 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 quick is a quick dive into two .NET 6 migration methods: Multi-targeting and what we’ve coined “Bridging,” and how you can implement them to start your NuGet migration!
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 6 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 6 library are very similar. Yes, the .NET 6 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:
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.
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 6, 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, it’s possible your library’s code will 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 .NET 5 or 6 (e.g. .NET Core).
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 .NET Core). 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 .NET 6+.
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.5.2 to 4.7, and 4.8 are expected to have long support times (maybe even infinitely in 4.8’s case).
Migrating is a good idea, however, for those who want all the new features and benefits of .NET 6. The new .NET v.Core series (.NET 5, 6, etc.) 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 using NuGet to make your .NET packages? Learn how to optimize your NuGet in the Enterprise; sign up for our free NuGet guide: