.NET classes, including the forms and controls used to build an OpenEdge GUI for .NET, reside in collections called assemblies. An application that includes .NET classes must have a list of the assemblies in which those classes are stored. This list of references is contained in a file called assemblies.xml.
An assemblies.xml file is automatically created for your Progress Developer Studio for OpenEdge project when you place a control on a form or manually add an assembly to the project. As you use .NET objects to build UI components, Progress Developer Studio for OpenEdge adds the appropriate assembly references to the file so that the assemblies.xml file for a project contains all references needed for that project.
Your application must have access to the assemblies at run time. Thus, the run-time environment must include all referenced assemblies.
By default, Progress Developer Studio for OpenEdge creates the assemblies.xml file in the project's root folder. To specify a different location, add -assemblies directory-path to the project startup parameters ( ). You can enter the absolute directory path or the path relative to the project working directory.
All controls installed with Progress Developer Studio for OpenEdge are automatically registered in the global assembly cache (GAC), the standard repository for .NET.assemblies that are designed for use by multiple applications running on the local machine. The GAC enables applications to locate and use all of the assemblies that it contains. Any assemblies used by the application that are not registered in the GAC must reside in the same directory as the assemblies.xml file. If you use such assemblies, be sure to copy them to that location. This requirement applies both to the run-time environment and to the design-time environment. Failure to keep the assemblies.xml file and the assemblies together in the same directory prevents applications from loading the controls at run time, and may cause various design-time issues.
For any ABL application that accesses .NET objects, the AVM automatically loads certain .NET assemblies, including the appropriate versions of:
ABL can therefore locate any .NET type that you reference from these assemblies without their being listed in the assemblies.xml file.