COM and .NET Interoperability

Regardless of what people may say, the Component Object Model (COM) is not dead. Let's face it; we've been developing COM objects with previous versions of Microsoft Visual Basic for too long to just throw away these painful and valuable investments. In previous versions of Visual Basic, developers relied on COM to segment their applications into physical chunks. More importantly, Visual Basic applications could consume the many COM objects provided by other applications and vendors. This allowed developers to assemble solutions from reusable components. A good example of this is the use of Visual Basic to automate Microsoft Excel through the COM interfaces provided by Excel. In the big picture, COM definitely has its place in application development. COM does have its shortcomings, some of which can lead to “DLL hell!”

COM evolved from the ashes of OLE 1.0 and ActiveX into a technology that allowed applications blocks (EXEs and DLLs) to communicate with each other regardless of their implementation through a structured set of interfaces. COM is a binary-compatible way of reusing code as opposed to source-compatible, meaning that a COM object is a COM object regardless of the language or tool that was used to create it. COM works on the premise that applications that consume COM objects don't need to know anything about the implementation of the object except for its interface, that is, the exact way the object exposes its properties and methods. These interfaces act as contracts between the COM object and those who want to consume it. In essence, the COM object states: “These are my methods and properties and this is how you can use them.” Consumers of this interface rely on this contract and it must always hold true. If the COM object changes the way it exposes its methods and properties, existing client applications would break.

COM relies heavily on the operating system and the system Registry for tracking and defining COM objects. Every COM object (and its interfaces) is registered in the system Registry. In fact, all classes that are exposed as a COM object must have their own unique identifier, called a CLSID. This CLSID uniquely identifies the object to the operating system. The operating system not only helps to represent COM objects but also plays a fairly significant role in instantiation of COM objects. The system Registry will store additional information about the COM class such as the location and name of the binary file that implements the class, the type of class (in-process or out-of-process), versions, and in some cases a Programmatic Identifier (ProgID). When a program wants to use a COM class, it provides the operating system with either the CLSID or ProgID of the COM class. The operating system is responsible for locating its implementation and allowing the calling application to use the methods and properties provided by COM class.

Despite the good things that COM provides, its implementation causes some problems in the real world. First, as I just stated, every COM class needs to be registered with the system Registry. This means that when deploying COM components, you must also register the COM classes in the system Registry using utilities like regsvr32.exe or with custom installation packages. Additionally, COM made it virtually impossible to have two different versions of the same COM class in different locations active at the same time. The system Registry allows only one location to be specified for every CLSID and only a single CLSID can be specified for every ProgID. Also, in some occasions the replacement of COM classes with newer versions break applications that relied on the previous version. In essence, the contracts that COM interfaces establish between the client application and the COM classes are relatively easy to break. For this reason, you might have heard the term “DLL hell” in reference to distribution issues associated with COM classes.

Again, however, COM isn't just going to go away with .NET—well, not right away. In fact, integration between .NET applications and COM is essential for the immediate future. For example, Microsoft Office still only exposes COM interfaces, so if you require any form of Microsoft Office automation, such as using Excel for calculations, analysis, and graphing, you need to be able to call, instantiate, and execute these COM objects from your Visual Basic. NET applications. Additionally, the opposite scenario might exist where you want COM clients to call your managed applications. Either case demonstrates the importance of finding some way of communicating between the COM and .NET worlds.