How does the Progress client handle .NET assembly loading

How does the Progress client handle assembly loading?
How does Progress locate and load .NET assemblies?
Does the assemblies.xml file need to be present when executing compiled R-code?
Are .NET Core libraries available in the GAC ? 

The Progress client will handle assembly loading differently depending on whether it is dealing with source code or compiled R-code:

1. The .NET framework relies on the assembly-qualified name of an assembly to resolve references.

The assembly-qualified name is the internal name of the assembly combined with the assembly version, culture, and public key and is used to create a unique value. Without having this full name, there is no way to run the code without explicitly loading the assemblies first; .NET will not be able to resolve the references.

Assemblies have both an Assembly Version and an Assembly File Version. The Assembly File Version is not part of the assembly-qualified name and can change without affecting the assembly resolution (a technique commonly used for intermediate builds and drop-in replacement hotfixes)

2. Source code requires the presence of a valid assemblies.xml file that references the latest version of all assemblies required by the code.

3. Compiled R-code has the assembly-qualified name of the classes required by the code compiled into it.

Compiled R-code does not require an assemblies.xml file. For assemblies that are not installed in the GAC or in .NET's search locations (see below) .DLLs can be placed in any folder and the -assemblies startup parameter must be used to reference this folder. 

Multiple versions of the same assembly can be registered in the GAC at the same time; the .NET framework relies on the assembly-qualified name to locate and load the version the application expects.

Note: With the introduction of .NET (Core), Microsoft has made the GAC obsolete and will therefor not be used anymore with .NET Core and .NET 5 and later versions.
For more information see following Microsoft article: Global assembly cache APIs are obsolete.

When only a later version of the assembly has been installed on the machine then it is a requirement that the current copy of %DLC%\bin\<client>.exe.config (e.g. prowin32.exe.config) contains redirects to the later assembly versions. For example, code compiled in 11.5.0 referencing Infragistics 14.2.20142.2010 requires redirection to Infragistics 14.2.20142.2092 when executing in 11.5.1; the entry in <client>.exe.config is as follows:
 

<dependentAssembly>
      <assemblyIdentity name="Infragistics4.Win.UltraWinEditors.v14.2" 
                   publicKeyToken="7dd5c3163f2cd0cb" culture="neutral" />
      <publisherPolicy apply="no"/>
      <bindingRedirect oldVersion="14.2.20142.2010" 
                       newVersion="14.2.20142.2092"/>    
    </dependentAssembly>

The addition of redirects to <client>.exe.config is performed automatically for .NET controls shipped with OpenEdge (e.g. from Infragistics or Telerik) when a Service Pack is applied. 

If the name of the assembly changes then the code must be re-compiled. Assembly redirection works only when the assembly name stays the same and only the version number changes. For example, the following looks like a version change but is qualified as an assembly name change:

4.  Locating Assemblies

To locate assemblies, the .NET CLR loaded by the Progress client searches the following locations in order:

• 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

For more information about assemblies.config, see the article Accessing assemblies from another project. and .NET assemblies in the documentation.

(**) The last 2 entries referencing %DLC% are configured in the probing privatePath setting of the <client>.exe.config file:
 

<probing privatePath="Infragistics\winforms;dotnetmsgs" />

The following results were generated using code compiled in 11.5.0 and tested against 11.5.1. Service Pack 1 for 11.5 upgrades the Infragistics versions shipped from 14.2.20142.2010 to 14.2.20142.2092.