.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.

In addition to maintaining the assemblies.xml file, Progress Developer Studio for OpenEdge also adds a Referenced Assemblies node to the Project Explorer view, providing a convenient list of the assemblies in use in the project. If your application uses .NET classes other than those you access with the Visual Designer, you can add them to the assemblies.xml file through a dialog that is accessible via right-clicking in the Project Explorer view (or via the Progress OpenEdge Properties page).
Note: When you delete a control with the Visual Designer, the assembly reference is not automatically removed from the assemblies.xml file or from the Project Explorer view. Although unused assembly references do no harm, if you want to delete them, you must do so manually. Use the Assemblies dialog in project properties (Project > Properties > OpenEdge > Progress > Assemblies) to do this.

Your application must have access to the assemblies at run time. Thus, the run-time environment must include all referenced assemblies.

Location of assemblies.xml and controls

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 (Project > Properties > Progress OpenEdge). 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.

Note: For more information about considerations related to .NET assemblies, see Manage ABL Applications.

Updating assembly references to use new controls

If you install a new version of an assembly, it is necessary to update existing assembly references in order to use the new controls in applications that you developed previously. OpenEdge provides an Update Assembly References tool to help you accomplish this. The tool runs independently outside of the Eclipse framework, but you can launch it from Progress Developer Studio for OpenEdge by means of an option on the OpenEdge > Migration menu.
Note: For more information, see Update assembly references.

Default assemblies

For any ABL application that accesses .NET objects, the AVM automatically loads certain .NET assemblies, including the appropriate versions of:

  • Progress.NetUI.dll — Assembly where all custom OpenEdge .NET classes reside
  • Mscorlib.dll — Assembly where all core Microsoft .NET classes reside
  • System.Windows.Forms.dll — Assembly where all Microsoft form and control classes reside
  • System.Drawing.dll — Assembly where all Microsoft graphics classes reside

ABL can therefore locate any .NET type that you reference from these assemblies without their being listed in the assemblies.xml file.