COM Interop

Interoperability between different architectures is a major issue facing programmers. The CORBA specification includes the Interworking Specification, which deals with interoperability between COM and CORBA. An RMI-to-IIOP bridge links Java and CORBA.

The CLR uses COM Interop to provide a gateway between components in the CLR and COM worlds . In essence, COM Interop works on metadata. Because both COM and the CLR describe their types with metadata, tools can read the metadata description of one type in one architecture and produce an appropriate metadata description for the other architecture. Tools can also automatically generate proxy objects; these proxy objects may be located in the client's and server's processes. They provide a local representation of the component by using the same execution semantics expected by their environment. For example, if a CLR component is accessing a COM component, it does not want to deal with issues such as interface navigation ( QueryInterface ) and memory management ( AddRef and Release ). Instead, the proxy object will handle interface navigation and lifetime issues for the COM component.

A few tools provide the interoperability functionality:

• Type Library Importer (tlbimp.exe) takes a type library and provides an assembly with metadata for the components.

• Type Library Exporter (tlbexp.exe) generates a type library description for a CLR assembly.

• Register Assembly (regasm.exe) provides Registry entries for an assembly so that COM components can find and activate objects.

The following program gives a short example of the COM Interop facilities at work. Listing 3.11 shows the IDL for a COM component. HelloATL is a small COM component ^[3] that displays a message box on the screen along with user -supplied text.

^[3] This application was originally written by Don Box.

Listing 3.11 Using COM Interop: HelloATL

 // helloatl.idl import "oaidl.idl"; [     object, uuid(FFA03426-9E54-11D0-BF81-0060975E6A6A),     dual, helpstring("IHelloATL Interface"),     pointer_default(unique) ] interface IHelloATL : IDispatch {     HRESULT Hello([in] BSTR bstr); } [     uuid(FFA03419-9E54-11D0-BF81-0060975E6A6A),     version(1.0), helpstring("HelloATL 1.0 Type Library") ] library HELLOATLLib {     importlib("stdole32.tlb");     [         uuid(FFA03427-9E54-11D0-BF81-0060975E6A6A),         helpstring("HelloATL Class")     ]     coclass HelloATL     {         [default] interface IHelloATL;     }; }; 

Compiling this IDL file and then running the resultant type library through the type library importer produces a CLR file. When opened in ILDASM, it produces the information shown in Figure 3.11.

Figure 3.11. Output of Listing 3.11

The type library importer has created two CLR interfaces and a CLR class. A small program is then written that uses the CLR metadata, as shown in Listing 3.12. Remember that these CLR types are merely proxies for the COM component; the COM component still does all the work.

Listing 3.12 Using the CLR metadata created by Listing 3.11

 using System; using System.Reflection; using HELLOATLLib; public class COMInterop {    public static int Main(String[] args)    {       HelloATL h = new HelloATL();       Type t = h.GetType();       Console.WriteLine(t.FullName);       Console.WriteLine(t.AssemblyQualifiedName);       Console.WriteLine(t.BaseType);       MethodInfo[] ma = t.GetMethods();       foreach(MethodInfo m in ma)          Console.WriteLine(m);       h.Hello("Hello World from COM/ATL");       return 0;    } } 

Running the program produces the following output:

 HELLOATLLib.HelloATL  HELLOATLLib.HelloATL, HELLOATLLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null System.__ComObject Void Hello(System.String) System.Runtime.Remoting.ObjRef CreateObjRef(System.Type) System.Object InitializeLifetimeService() System.Object GetLifetimeService() Int32 GetHashCode() Boolean Equals(System.Object) System.String ToString() System.Type GetType() 

It also produces the message box shown in Figure 3.12.

Figure 3.12. Output of Listing 3.12