Ignite Microsoft has previewed a new upgrade assistant to help developers port .NET Framework applications to .NET 5.0, but it is a long way from a complete solution.
When Microsoft forked the .NET Framework to become the open source .NET Core (now just known as .NET) it created a problem: no easy upgrade path for existing .NET Framework applications.
The issues range from trivial to showstoppers like the fact that the entire web forms framework (the original web application framework for .NET) is missing. This need to support existing .NET Framework applications is an issue that will become increasingly annoying as they age.
A row of promising green “Complete” statements gave us hope for a successful migration of our .NET Framework application
The .NET Framework is still supported; version 4.5.2 and later are defined as a component of Windows and therefore follows the support lifecycle for Windows. Older .NET Framework versions are more problematic but the upgrade to 4.x is easier than porting to .NET Core.
However, Microsoft has stated that .NET Framework 4.8, released in April 2019, is the last major version and that “all future investment will be in .NET Core.” Better container support, Linux compatibility, and the benefit of new features and performance improvements, will all be reserved for applications targeting .NET Core / .NET 5.0 and higher.
Building the converted application failed: tweaks will be needed before it runs, and then it is time for testing
How, then, does one port a legacy application?
It is easier than it was, since now even Windows Forms and Windows Presentation Foundations desktop applications run in .NET Core – though of course only on Windows.
Pure C# code is normally easy to port, but the problem comes with dependency and library differences that can be hard to resolve. Applications well covered by unit tests are safer to port as there is a better chance of finding differences in behaviour that may cause unexpected results.
A robust approach, perhaps, is to start a new project and copy over existing code piece by piece; but this is slow. What about simply running a tool to migrate a project? It is a nice idea, and lacking from Microsoft until now, though a portability analyzer exists.
Amazon Web Services spotted the gap and released its own open source porting assistant though it is not without issues. There is also a try-convert tool, based on the work of Microsoft engineer Srivatsn Narayanan, that comes with the warning: "This tool is not supported in any way. Nobody will be on the hook for fixing any issues with it."
At Ignite, Microsoft introduced its new tool called .NET Upgrade Assistant, which is based on try-convert, though Principal PM Lead Cathy Sullivan glossed over support limitations in the post introducing the project. The tool is in preview and open source on GitHub.
"The tool automates more tasks in the upgrade process that you would normally do manually like upgrading to the new SDK-style project format, re-targeting them to .NET 5 and updating NuGet package dependencies," said Sullivan.
It is intended to work on ASP.NET MVC, Windows Forms, and WPF applications. A third party, Optimizely, assisted with the development of the tool because it wished to upgrade its "large ASP.NET application portfolio," she added.
How well does it work?
We took it for a spin. Installation is easy, using the dotnet tool command-line utility, and installing first try-convert and then the upgrade assistant. We picked for our first attempt an old Windows Forms application built with Visual Basic. No go: “
Visual Basic is not supported.”
Next up was a small ASP.NET MVC application which uses Azure AD authentication. The upgrade assistant chewed through this smoothly, going through several steps, including converting the project, updating the target framework (TFM), and applying fixes to the C# source.
Everything looked good until we loaded and attempted to build the result. "
Consider app.config remapping of assembly "Microsoft.Data.Services.Client … Choosing "Microsoft.Data.Services.Client, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35" arbitrarily," said Visual Studio.
Then the build failed with a number of errors, failing to find an entrypoint, and declaring that: "
The name HttpUtility does not exist in the current context."
Such things are to be expected, and Sullivan noted that "manual changes will still need to be made because these require knowledge of the app and how it's intended to function."
The question is: does it accelerate porting, compared to a more DIY approach? In our case, it looks like some more work is required before we know the answer. Once developers go to the effort of porting a project, it is common to upgrade libraries to new versions and that often requires code changes that go beyond those required by the port alone.
It can easily become a substantial effort, and that, along with the risk of unexpected output, is why legacy .NET Framework applications will continue running in many organisations for a long time yet. ®