.NET 6 Upgrade - Part 1 - Port Assistant
Upgrading from .NET Framework to .NET 6 is possible via assistants, in this article we are exploring the Porting Assistant for .NET provided by AWS. This is part 1 of 2 in this series.
The assistant
The tool provides a comprehensive analysis of the .NET Framework application, generating a .NET 6 compatibility assessment.
Looking at the graph below, the tool starts by scanning the .NET Framework assemblies, and creating the assessment report, and from there you have the option to migrate.
Source: AWS1
What is great about the tooling is the assessment report, which you can use to inform stakeholders about the challenges with the migration. The tool is not going to do any miracles if packages are incompatible, but it will point those out for you.
An example
Do you remember WebForms? The precursor of ASP.NET MVC. Let's grab an old WebApi from this source: https://github.com/aspnet/samples/tree/main/samples/aspnet/WebApi/WebFormSample
Interestingly enough this solution works on .NET Framework 4.5, but I didn't dare to install it on my current machine, so I manually tweaked the Project file to .NET Framework 4.8.
I recommend a separate machine, probably a VM to run this sort of exercise.
If you are in Visual Studio 2022 you get this warning.
As you do the framework change, it modifies the project Target Framework:
<TargetFrameworkVersion>v4.8</TargetFrameworkVersion>
The Solution Explorer looks like this:
If you run both Client and WebForm projects, they will work:
The nitty-gritty
There are some prerequisites you need to be aware of, but to migrate from .NET Framework 4.5 to .NET 6, you must have those SDKs installed.
I have not tried the .NET Visual Studio IDE extension, but that's also an option. You basically need more RAM on your machine if you decided to use this extension.
Opening the tool
After selecting the solution file, the assessment starts automatically:
Assessment
After the assessment you get some results for analysis:
You can either delve into details using the tool UI, or you can export the results in a zip file that contains detailed CSVs:
Porting
From here you can port the solution and then validate whether it still works, and the impacted areas.
You can try porting to a new location or doing an in-place upgrade. This is up to you or the team you are working on to define:
You get some sort of summary that you need to confirm to port:
And after a few minutes the project is ported:
The new ported solution
So the solution was ported from .NET Framework 4.8 to .NET 6, but will it work?
Because we had so many incompatibilities, as expected, the solution will not even compile. This will give you an idea of the efforts required, so you can provide estimates, and get the team to work on it.
If you compare folders, files you can see that now things were upgraded to .NET 6, to start with the Project Files:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.4" />
<PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
</ItemGroup>
<ItemGroup Label="PortingInfo">
<!-- DO NOT REMOVE WHILE PORTING
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\Microsoft.CSharp.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\mscorlib.dll
C:\temp\demo\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Core.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Data.DataSetExtensions.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Data.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Net.Http.dll
C:\temp\demo\packages\Microsoft.AspNet.WebApi.Client.5.2.0\lib\net45\System.Net.Http.Formatting.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Xml.dll
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.8\System.Xml.Linq.dll
-->
</ItemGroup>
</Project>
On the client, you could modify the references and get it to work, as it is more straightforward, but the WebForm Api (now an ASPNET Core) will require more effort to get it to run.
My Opinion
I was impressed by the tooling initially created by AWS, and then open-sourced and maintained by the community.
The Visual is great, and it does a comprehensive assessment of the differences found when migrating from .NET Framework to .NET Core.
This will help you and your team to decide whether to port your solution or not (depending on the efforts required), keeping stakeholders informed about the challenges.
The open-source project is available at https://github.com/aws/porting-assistant-dotnet-client.
Full Series
.NET 6 Upgrade - Part 1 - Port Assistant
- How it works How it works↩