.NET environment

The .NET environment is comprised of extensions to the OpenEdge client, ABL elements, and tools that support the ability to access .NET objects from ABL much as if they were native ABL objects.

ABL access to .NET objects provides a way to build an alternative Windows desktop user interface for ABL applications based on .NET Windows Forms forms and controls. ABL enables your application to use the GUI for .NET together with the traditional OpenEdge GUI, and provides particular support for using .NET forms and ABL windows together in the same ABL session.

You can also use non-GUI .NET objects for any functionality you need (on both Windows and Linux).

ABL provides access to objects in a .NET assembly. The following figure shows that all class-based objects in ABL are derived from the Progress.Lang.Object root class.

ABL supports .NET objects within ABL. ABL can interact with .NET objects using enhanced ABL features without, itself, becoming a native .NET language. References to .NET objects in ABL are made using object-oriented (OO) syntax. You can make those references from procedural or class-based code or any combination.

The following figure represents the OpenEdge .NET architecture at a high level. In support of .NET objects and events, ABL incorporates the ABL Virtual Machine (AVM) and the .NET Common Language Runtime (CLR) within a single OpenEdge client process. The CLR is the core run-time engine for executing applications in the runtime.

OpenEdge supports two separate .NET Common Language Runtimes (CLRs): one for .NET Framework 4.8 and the other for .NET. You control which one to use by installing the desired .NET runtime and using the .NET Common Language Runtime (-clrnetcore) startup parameter if using .NET. On Windows, if the startup parameter is not specified, the AVM loads .NET Framework 4.8. On Linux, if the startup parameter is not specified, .NET is not loaded.

What makes communication between the ABL and .NET possible is the bridge that provides the transformation by allowing information to go back and forth between the AVM and the CLR. When the CLR gets a request, such as to run a .NET method, the bridge converts the data between the CLR and the AVM.

On the AVM side you define your components, do your data access, do I/O blocking (a version of the WAIT-FOR statement), and write event handlers in ABL. On the .NET side, the CLR handles the visualization of the .NET UI. The user interacts with the CLR, because that is where the user interface is running.

The figure above depicts a simplified sample flow of control between the AVM and the CLR.

The following steps pertain to an application you could write on the Windows platform:

1. In ABL, a new .NET form is created. The form subscribes an ABL event handler method to its FormClosing event, and the form is run.
2. The request is passed over the bridge to the CLR to create the .NET form.
3. The form is displayed using a .NET method specified by the WAIT-FOR statement.
4. The user does some work and closes the form.
5. The FormClosing event message is sent to all subscribers from .NET.
6. The bridge sends the message to the AVM and causes the event handler method to run.

There is no one application architecture supported by GUI for .NET. You can either keep your existing architecture or follow a modularized design such as the OpenEdge Reference Architecture (OERA). There is no requirement to change your application architecture, though some applications might require more modifications than others to provide a GUI for .NET interface that communicates with existing data management and business logic. There might be compelling reasons to update parts of your application architecture to take advantage of advanced features that GUI for .NET provides. Many architectural topologies are supported, including fat client, client/server, and n-tier. GUI for .NET does not require you to change from one topology to another.

Just as there is no one UI technology that is applicable for all of today's applications, an application's primary use often dictates what UI technology works best. To put GUI for .NET development in perspective, it helps to compare this technology with other OpenEdge UI technologies.

The following table lists the various OpenEdge UI technologies, their primary use, and what development tools are best suited for building these types of business applications. These are suggestions; the table is not meant to be all-inclusive and there is overlap between technologies, their primary use, and tools.

Table 1. OpenEdge UI technologies

UI Technology	Primary Use	Tools to Use
GUI for .NET	Build modern, state-of-the-art GUIs for Microsoft Windows in ABL	PDSOE (Progress Developer Studio for OpenEdge) Visual Designer
OpenEdge GUI	Build Windows user interface look and feel	OpenEdge Studio PDSOE AppBuilder PDSOE Procedure Editor
Open Client	Build alternate UIs (.NET & Java™) to OpenEdge applications, requires PAS for OpenEdge	Open Client Toolkit
Character	Build traditional green-screen user interfaces	OpenEdge Studio PDSOE Procedure Editor 4GL Development System

WebClient can be used as a deployment platform for ABL applications on Windows.