In this article, we will discuss about the things we should consider when migrating code from .NET Framework to .NET. The Migration of project from .NET Framework to .NET is relatively a straightforward task but the complexity of the project determines how much effort is involved after the initial migration.Applications which are created on .NET Framework might have Windows Presentation Foundation (WPF) or Windows Forms (WF) components, in which case, the following dependencies must be considered before we migrate WPF or WF Applications.

1. The project files of .NET Framework are different from that of .NET files.
2. The APIs in the source project may not be available in .NET.
3. Third party controls and libraries may not be available in .NET.

Open-source versions of Windows Forms and WPF are available in .NET and it includes enhancements over .NET Framework.

Technologies that don’t exist in .NET

Here are few technologies which exist in .NET Framework but not in .NET.

1. Application Domains

.NET don’t support creation of additional Application Domains. For code isolation, as an alternate we must use sperate process or containers.

2. Remoting

Remoting was found to be a problematic architecture. It was used for communication across the application domain which is no longer supported in .NET. Remoting also required run-time support, which made it expensive to maintain.

3. Code Access Security

Code Access Security (CAS) is a sandboxing technique which was deprecated in .NET Framework 4.0. CAS is no longer treated as a security boundary as there were too many cases where the elevation of privileges occurred during runtime in .NET Framework. In .NET, it uses security boundary provided by the operating system such as virtualization, containers, or user accounts instead of CAS.

4. Security Transparency

Like CAS, Security Transparency is a sandboxing technique which is no longer Supported in .NET.

 

Tools which can be used to assist in migration

There are some tools which can help you to automate some aspects of migration instead of manually migrating your application form .NET t Framework to .NET.

1. .NET Upgrade Assistant

.NET Upgrade Assistant is a command line tool which can be used to migrate different types of applications in .NET Framework to .NET. It requires the installation of analyzers which can help in completing the migration. In most cases, even after running the tool it requires additional effort to complete the migration.

           Currently, this tool supports the migration of following .NET Framework Apps to .NET

•   .NET Framework Windows Form Apps
•   .NET Framework WPF apps
•   .NET Native UWP apps
•   .NET Framework ASP.NET MVC apps
•   .NET Framework console apps
•   .NET Framework class libraries

 

2. try-convert

This is a .NET t global tool which can convert a project or entire solution to .NET SDK. However, if your project has complicated build process, or API usage which are incompatible with .NET, or unsupported project type then this tool isn’t recommended.

This tool works by loading a given project and then it evaluates to get a list of all properties and items. It then replaces the project in memory with a simple .NET SDK based template and then re-evaluates it.

3. .NET Portability Analyzer

This is a tool which analyzes assemblies and gives a detailed report on .NET APIs that are missing for the applications or libraries to be portable on .NET. It is also offered as a Visual Studio Extension. Once the project is converted to .NET, use any Roslyn-based platform analyzer to identify the APIs that throw exceptions like Platform not supported exception or other compatibility issues.

 

Things to consider before Migration

Before migrating the application to .NET, we need to consider following things in order.

1. Use .NET Upgrade Assistant to migrate your project
2. Examine your dependencies first
3. Migrate from a NuGet packages.config file to Package Reference settings in the project file. Convert the package.config file using Visual Studio.
4. Upgrade to latest project file format.
5. Target migrating to .NET 6 which has long-term support.
6. Consider targeting  .NET Standard 2.0 while migrating a library that may be also used with .NET Framework projects .

Always add reference to Microsoft.Windows.Compactibility NuGet Package, it contains a large portion of  the .NET Framework API surface and is available to .NET via this package.