Assemblies in OpenEdge – Tips & tricks

Nowadays Openedge comes with an enriched GUI interface. This is implemented based on Infragistics components, deployed as DLL libraries.

In other situations, you may need to use functionality implemented by 3-rd party companies, like Curl HTTP library, which is available as DLL libraries.

When you want to use this kind of external components -packed as DLL libraries-, you will need to make use of DLL integration capabilities of OpenEdge.

Internal functions defined into the DLL can be called statically or dynamically.
For static calls the DLL must be make known to Openedge by adding it into assembly reference list (assemblies.xml), then the code can reference the DLL inner namespace, objects and methods.
The DLL is identified by so called assembly-qualified name, which is a combination of assembly version, culture and public key. It is used to identify the DLL assembly and load it automatically. Without this there is no way to run the code without loading explicitly loading the assemblies first.
In case of dynamic calls, either you provide the full path to the DLL library file or load it explicitly beforehand. But most easy is to use static calls because Openedge is able to verify syntax against DLL components.

Below are few thought about how the DLL assemblies are located and loaded by Openedge.

Locate assemblies

Openedge in cooperation with .Net Framework searches the followings paths to locate the assemblies:

Global Assembly Cache (GAC)
%DLC%\bin
%DLC%\bin\Infragistics\winforms (**)
%DLC%\bin\telerik\winforms (**)
%DLC%\bin\dotnetmsgs (**)
-assemblies location handled by the Progress AVM itself
assemblies.config location
Current working directory

Assembly References File (assemblies.xml)

allows OpenEdge to make DLL available to project’s source code
it contains assembly-qualified name components of the DLLs
must be placed in folder specified by -assemblies startup parameter, or working directory if -assemblies parameter is missing
it is not used when running compiled .r-code. Dll assembly-qualified name is embedded into .r-code, therefore don’t need to be deployed together with r-code files.

assemblies.config

placed in same folder as assemblies.xml
specifies a list of subfolders, allowing DLLs to be organized by subfolder folders

Organize DLLs on subfolders within assemblies folder

Large number of DLL libraries can become hard to maintain. Organizing them into subfolder it is a good practice. This can be achieved by using assemblies.config file.

Structure of assemblies.config:

</assemblyBinding>

</runtime>

</configuration>

Case study: 32-bit & 64-bit DLLs in assemblies folder

Suppose we have the following situation:

32-bit dll is available in assemblies folder
need to install 64-bit version for 64-bit platform and, also keep 32-bit version available
there must be only one assemblies folder for simplify deployment
32-bit and 64-bit versions of an assemblies have the same name
can’t register dlls to GAC due to deployment process.
assemblies folder hosted several platform independent compiled dll and also 32-bit version of dll

Considerations:

Having 32-bit and 64-bit versions of an assemblies with the same name, impede storing them in same assembly folder. It would be good to have them registered in GAC, where we can have 32-bit and 64-bit DLLs with the same name and Openedge will pick the right one corresponding with running platform. But registering to GAC is not a solution due to deployment process.

Solution:

We needed to find a solution to make both files available and let OpenEdge load the right one.

Solution is to use assemblies.config file to define a subfolder for 64-bit version. The file will look like this:

</assemblyBinding>

</runtime>

</configuration>

Place 32-bit version of the file in /assemblies/ folder and 64-bit version of the DLL into /assemblies/x64/

Having this assemblies.config file, when running with 32-bit platform Openedge will identify the 32-bit DLL in assemblies folder. While when running 64-bit version, Openedge will not be able to load the 32-bit version from assemblies folder but will find the 64-bit version into the subfolder defined in assemblies.config file.
Of course, the platform independent DLLs can be placed directly into /assemblies/ folder and will be loaded when running both platforms.

Referencies:

https://community-archive.progress.com/forums/00019/39173.html

https://community.progress.com/s/article/How-does-the-Progress-client-handle-NET-assembly-loading

https://progress.my.site.com/s/article/Accessing-assemblies-from-another-project

Author: Daniel Baciu, Tech Lead

Working in Progress since 2000, Daniel is passionate about writing frameworks, supportive code, and making things work seamlessly. He focuses on designing and building customer applications, integrating with a wide range of systems and devices, and creating efficient, maintainable solutions that stand the test of time.