How to Test if Your App is Portable to .NET 5

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.

Using the .NET Portability Analyzer

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:

1. Download the extension from the Visual Studio Marketplace (under Extensions | Manage Extensions)
2. Close and reopen Visual Studio for the extension (VSIX) to be fully installed.
3. Locate the settings under Tools | Options > .NET Portability Analyzer
4. In the settings you can choose the target version of .NET and the report format (.html, xlsx, .json). The HTML report is easier to read; however, the Excel report contains more details. So why not generate both?

5. To analyze a project open in Visual Studio, right-click Project in the Solution Explorer and select Analyze Project Portability.
6. After the analyzer analyzes, you will see a pop-up with the generated reports.

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:

• System.Data.OleDb - Typically, applications referenced this assembly for connecting to SQL Server. For .NET 5, Microsoft has made this package available separately on nuget.org. But the preferred migration solution here is to switch to SqlClient. There shouldn’t be any loss in functionality, but some code will need to be rewritten.
• System.Windows.Forms.Toolbar - The classic windows toolbar and everything associated with it is not supported in .NET 5. But you may wonder how can we not have toolbars? Apparently, Microsoft replaced Toolbar with ToolStrip at some point. You can find a full list of which controls have been replaced with newer versions here, including other common controls like ContextMenu and DataGrid.

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.

Using .NET Framework Libraries in .NET 5 Apps

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.

Portability of ComponentOne Controls

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.

.NET Portability Analyzer Summary

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