By now, you've probably heard about .NET 5 and all of the benefits it brings to .NET Windows applications. But do you know how portable your applications are to .NET 5?
Microsoft has published a few tools to help with migration, specifically the .NET Portability Analyzer and the Try-Convert tool. The analyzer generates a report on what libraries are supported and not, whereas the Try-Convert tool actually converts your project files.
In this blog, you will receive a rundown of the .NET Portability Analyzer and how third party components like those from GrapeCity fit into the equation.
If your project has potential issues, such as referencing unsupported libraries, the analyzer helps you identify those problems. It provides a detailed report on which APIs your app uses that won't be supported if you were to port it to .NET Core or .NET 5.
To get started:
Next, let’s analyze the HTML report.
As you can see, the report says that this application is about 91% portable to .NET 5. Note that the report seems to include .NET Core and .NET 5 + Platform Extensions whether you select them or not.
Further down the report, you can see which APIs are not supported.
This sample application uses a couple of problematic APIs: System.Data.OleDb and System.Windows.Forms.Toolbar. If we were to port this application to .NET 5, we would need to replace them and possibly rewrite the code. Browsing online for solutions, I found the following suggestions:
Since both of these issues can be easily resolved with new packages or controls that are available separately, this application's portability becomes 100% if you look in the .NET 5 + Platform Extensions column of the report.
That's it. Once you can find suitable replacements for all problematic APIs, your application is ready to migrate to .NET 5 - oh, except one last thing. Third-party libraries will not show up in the .NET Portability Analyzer.
If you look at the Excel report, you will notice they get listed under "Unresolved Assemblies". For 3rd party libraries, you should check out the vendor to see if they have .NET 5-ready versions ready to go. If they do – then consider it portable. If not, then you may need to find alternatives.
Keep in mind, in many cases, you can continue to use older versions of .NET Framework libraries in .NET 5 applications. The one downside is that it means the end-user must have a .NET Framework installed on their machine. One of the benefits of .NET 5 was eliminating this prerequisite since you can now package .NET in its entirety with your application. Still, this is not possible if you are using .NET Framework libraries anywhere in your app.
Secondly, at this time, there is still an issue using .NET framework components in the .NET 5 designer. If you need full design-time, then one workaround is to add a .NET framework project to your .NET 5 solution and link to any forms in your application. If you open the linked form from the framework project, you can use its fully-functioning designer and continue to build and run the .NET 5 project.
If you were to run any of our .NET 4.5.2 WinForms and WPF samples, they would return 100% portable because we've already updated them to support .NET Core and .NET 5. For the demonstration above, I chose an old sample project that used .NET 4.0 controls to see more interesting results. But as of this blog publication, we have not ported all controls to .NET 5.
We plan to complete porting the controls by the end of 2021, handling more popular controls first. You can find the most up to date list of controls in our latest .NET 5 release blogs, or check out the ComponentOne .NET 5 roadmap here.
Again, regarding the portability of 3rd party controls – if the control or library is available and supports .NET 5 according to the vendor – then consider it portable.
So that’s basically the .NET Portability Analyzer. It lets you get a rough idea of how portable your application is. You can use this tool to help determine if your application is a good candidate for migration. From the report's list, you can see if there will be problems by investigating each item that won't migrate and research if it's supported through a different library.
I’ll end this article with a few random migration tips - If your solution has multiple projects, you should analyze them one by one. It’s easier by following a bottom-up approach. Projects with fewer dependencies should be migrated to .NET 5 first, followed by those that depend on them. Projects that do not rely on UI should be ported to .NET Core or .NET Standard.
Related Video: Tips on Migrating to .NET 5