You may wish to migrate your existing OpenEdge application from .NET Framework to .NET on Windows. Some of the benefits include better performance and moving to an open-source developer platform that allows you to build many types of applications.

This topic provides general guidance for migrating your existing OpenEdge .NET Framework application to .NET. The basic steps are:
  1. Identify application dependencies
  2. Locate .NET compatible assemblies
  3. Identify differences between available .NET APIs
  4. Gather required assemblies into a new assemblies folder
  5. Address any API changes
  6. Recompile your application
  7. Test your application

Identify application dependencies

Review your application and identify any third-party .NET assemblies it is using. These libraries, especially those that make use of any .NET Desktop functionality (WinForms and WPF (Windows Presentation Foundation)), are unlikely to work with .NET. You will need to contact your vendor for updated assemblies.

Locate .NET compatible assemblies

The .NET and .NET Desktop runtimes included with the .NET installation package provide many areas of identical functionality. However, in some areas, the functionality is quite different. You may need to locate assemblies that work with .NET that provide similar capabilities to an existing installation. You can contact your vendor and/or read their documentation. Another source of assemblies is the https://nuget.org website. This website provides many thousands of packages, often with many separate versions and variants for both .NET Framework and .NET.

Note that not every assembly is available with .NET. For very old projects it may be necessary to build the assembly from source, if that is available, or select an entirely different library that works with .NET.

Identify differences between available .NET APIs

You should familiarize yourself with the documentation from both .NET, and your assembly vendor’s changes between versions. Pay special attention to changes to APIs that may have behavioral or signature differences between the .NET Framework and .NET releases.

Gather required assemblies into a new assemblies folder

Once you have all the assemblies your application requires for .NET, place them together in a separate assemblies folder. You will need to construct a new assemblies.xml file and place that into this folder. Progress does not recommend you edit an existing assemblies.xml file. While the format of assemblies.xml file remains the same, it is better to avoid mixing .NET Framework assemblies and .NET assemblies in the same folder. In many cases, the assemblies will likely have the same name between the different .NET versions, making storing two different versions in the same folder impossible. There may also be dependency differences that require separate assembly.xml entries.

You can use the existing Assembly References tool (proasmref) to construct a new assemblies.xml file. The proasmref tool can load the assembly information for both .NET Framework assemblies and .NET-targeted assemblies. When using proasmref to construct a new assemblies.xml file, do not select any assemblies from the GAC as .NET will not be able to locate them.

Address any API changes

If there are any API changes you are aware of, you will need to make ABL code changes. If you are using any deprecated or removed functionality, you should attempt to address these if the source code for your application needs to remain compatible with both .NET Framework and .NET.

Recompile your application

Update the OpenEdge startup parameters to include the -clrnetcore startup parameter and change the -assemblies parameter to point to the new assemblies folder containing only the .NET assemblies and the assemblies.xml file.

At this point, if you are confident your application will compile without further ABL code changes, you can attempt to recompile your ABL application and address any compilation failures.

If your application successfully compiles, you can attempt to run it to ensure it behaves correctly. You may find that APIs available with .NET behave differently even though they are named the same as the .NET Framework versions.

Test your application

You will of course need to test the ABL application with the same set of assemblies used to compile it.

Note: If you need to go back to using .NET Framework, you will need to recompile your application. The assembly versions for .NET libraries are different. Running r-code compiled for one .NET runtime on a different .NET runtime (for example, .NET to .NET Framework or vice-versa) will result in an error:
System.IO.FileNotFoundException: Could not load file or assembly...or one of its dependencies.
The system cannot find the file specified.