ABL and .NET organize their class-based type hierarchies using different mechanisms. ABL organizes user-defined types into packages (which correspond to physical directory paths on PROPATH) and stores the types in class definition (.cls) files (which you compile into r-code (.r) files). Packages allow user-defined types to be both associated in a hierarchy and uniquely identified. To locate an ABL user-defined class or interface during compilation, ABL must find its class definition file within a specified package relative to PROPATH. And to access a compiled ABL class or interface at run time, ABL must find the corresponding r-code file in the same package as the class definition file from which it is compiled. For more information on how ABL organizes user-defined types using packages, see OpenEdge Development: Object-oriented Programming.
.NET, on the other hand, organizes its object types into namespaces and stores the types in assembly files (assemblies). An assembly can be a dynamic link library (DLL) or executable (EXE) file that is specially formatted to store one or more types associated with their individual namespaces. A .NET namespace is analogous to an ABL package in that it provides a means to organize and uniquely identify types, but instead of being associated with an actual directory structure where the type definition is stored, a namespace is a completely logical construct that is associated with each type that is stored in an assembly. Assemblies provide several features for .NET types, including versioning, security, and localization support, all of which are incorporated into the format of the name used to identify the assembly. Also, the assembly where a given .NET type is defined can reside in any one of several locations on your system, and you must have access to this assembly both to compile and run an ABL application that references that .NET type. For more information on .NET namespaces and assemblies, see the Microsoft .NET documentation.
From the viewpoint of ABL programming, you code ABL packages for ABL user-defined type references and namespaces for .NET type references using the same syntax, and they can appear in most of the same coding contexts (see
Referencing .NET class and interface types). In addition, for .NET type references, you sometimes have to use an external tool to explicitly identify the assemblies where .NET types are stored in order to compile and run ABL code that references them.
