The .NET 6 preview has been out since February at this point, with version 4 released at the end of May. This preview provides an excellent way for folks already on .NET 5 to give the next version a test run before the support period ends, and they have to make a move quickly. It also provides .NET Framework users a new reason to look at the new .NET and consider if .NET 6 is right for them.
Here we will summarize the broad-stroke changes from .NET 5 to .NET 6 and discuss how you can start getting ready for the transition.
How Does .NET 6 Differ from .NET 5?
The first thing to mention about .NET 6 is that it is a Long Term Support release, unlike .NET 5. .NET 6 will receive three years of support, instead of just one. This pattern will continue for every even-numbered version of .NET (reference the chart above to see .NET support periods). For many organizations, this makes .NET 6 the first version of the new .NET they can use, as they stick strictly to LTS releases. This makes the release of .NET 6 a pretty significant paradigm shift.
Otherwise, .NET 6 has mainly expanded on the ideas of .NET 5, including these items:
.NET 6 is focusing on broadening the platforms developers can target for their applications. For example, with .NET 6 you can use Blazor to make desktop native applications.
Xamerin is receiving new UI tools and broadened support throughout the .NET ecosystem with faster build and deploy times.
They are improving Linux enterprise support, diagnostic tools, and package reliability.
Better cloud application support, including specific features for applications using gRPC.
Microsoft has been highly public with their priorities for .NET 6, and you can browse through them here. Overall, the focus is improving the .NET experience for developers targeting non-Windows platforms. If your organization is looking to support other operating systems better, .NET 6 will have many valuable features.
How to Start Planning for .NET 6
There are two scenarios for migrating to .NET 6:
- You are on .NET Core/.NET 5 already and just want to know the hiccups for moving to the newest version.
- You are on .NET Framework and still need to work out getting your application compatible with .NET Core in general.
Scenario one is much simpler. In general, the technology you are using will work. As far as specific breaking changes, Microsoft has already put together an extensive list with the main issues revolving around specific ASP.NET Core functionalities.
Scenario two is a bit more complicated but familiar. The same hurdles that make migrating from .NET Framework to .NET 5 difficult apply to .NET 6. Let’s take a look at common .NET Framework technologies:
|Part of .NET 6?||Potential Alternatives||Main Migration Complications|
|WinForms||Yes||Unnecessary||Incompatible Dependencies, few more breaking changes compared to .NET 5|
|Web Forms||No||Razor Pages, Blazor, ASP.NET Core MVC||Alternatives require a rewrite, alternatives may not replicate WebForms functionality 100%.|
|Windows Workflow Foundation||No||CoreWF, move to a different workflow framework, drop a workflow entirely||CoreWF is not a complete product, Windows Workflow Foundation projects tend to use many other .NET Framework components, alternatives may require a rewrite, alternatives may not replicate the functionality 100%.|
|WCF||No||gRPC, ASP.NET Core MVC, CoreWCF||CoreWCF is not a complete product, alternatives may require a rewrite.|
The compatibility of .NET Framework technologies has stayed consistent between .NET 5 and .NET 6 (although WinForms has a few more breaking changes in .NET 6 than .NET 5). So any technology that wasn’t brought into .NET 5 will not work on .NET 6.
But the good news is that developers on .NET Framework can benefit from the relatively easy transition from .NET 5 to .NET 6 as well. You can get ahead of the shift in November by seeing what you can migrate to .NET 5 right now if you are using WPF or WinForms. To start, test porting the application with tryconvert just to find out what works and what doesn’t work. Then, run the .NET portability analyzer to get a look at potential compatibility issues with your dependencies. These tools won’t magically port your application, but they will help put the work into perspective. From there, you can start assessing the required changes for migration, and set a realistic schedule.
What About Unsupported Technologies?
If you are using Web Forms or Windows Workflow Foundation, your application will require a rewrite. For Web Forms, start testing Razor Pages, Blazor, and ASP.NET Core MVC and see which technology will best fill in the gaps.
Windows Workflow Foundation will require a much longer look. Not only is it not ported over, but components like WCF used in conjunction have not been ported as well. CoreWF (the recommended .NET 5 replacement) may become good enough for many users, but it is not production-ready right now. If you need to migrate relatively soon, you can read more about migrating from Windows Workflow Foundation here.
WCF applications will also require a rewrite. The good news is, we make a tool that can assist rewrites to gRPC: Visual ReCode. Visual ReCode is a Visual Studio extension that rewrites your WCF services to gRPC for .NET Core and .NET 5 right now. This way, moving to .NET 6 will be faster in November. You can learn more about it on our features page, or try it yourself with our free trial in the link below.