Integration Capabilities in the .NET Framework

COM Interoperability

The CLR can interoperate with unmanaged code such as COM components, ActiveX controls, and (unmanaged) DLLs via an interoperability layer. These components have an associated type library that defines their interfaces, and in the .NET Framework the tlbimp tool allows for the generation of this interoperability layer. It is important to note here that .NET assemblies are compiled into DLLs for many project types (class libraries, Web projects and so on), but these differ from COM DLLs in that they are managed code, run by the CLR and stored in the global assembly cache (GAC)as opposed to unmanaged DLLs, which reside in specific application directories or are registered using the system registry. The latter type of DLL has led to the infamous "DLL hell" where different versions of the same DLL may be deployed to the same directory or may be registered over each other in the system registry, leading to system brittleness.

To interoperate with these unmanaged file types, this tool should be used, which converts the type definitions that are found within a COM type library into the equivalent definitions for a CLR assembly. The output is an assembly that contains runtime metadata for the types defined in the original library. Tools such as the MSIL disassembler (Ildasm.exe) may be used to inspect this file.

Using the type library importer is very straightforward. To generate an assembly that allows the developer to interoperate with a COM component whose type library is defined in myComponent.tlb, he or she would issue the following command:

Tlbimp myComponent.tlb /out:myComponent.dll

This generates a managed component called myComponent.dll that runs on the CLR but interoperates with the unmanaged COM component.

When using COM Interop, either side can call the other (Figure 2-2), and as such, COM can be a server to managed code applications or a client of them.

Figure 2-2. COM Interop is two-way.

Platform Invocation

Platform Invocation, commonly referred to as P/Invoke, enables managed code to call functions that are exported from an unmanaged library. It differs from COM Interoperability chiefly in that it doesn't allow unmanaged code to call back into managed code. It is achieved through DLLImport attributes within C# code like the following:

[DllImport("mycomponent.dll")] static extern Boolean MyFunction(UInt32 nMyParameter);

This is all that is required for managed code to be able to call the unmanaged MyFunction API. To call it from the code is straightforward:

bool bReturn = MyFunction(0);

The extern keyword indicates to the compiler that the method is implemented by a function that is exported from a DLL, which is specified by the DLLImport. It then understands that a method body isn't expected.

An interesting aspect of this is in the data types and how they are marshaled. The code snippet just listed defines the return type as a Boolean (fully qualified as a System.Boolean) and the parameter being passed in as a UInt32. These data types do not exist within C or C++ with which an unmanaged component such as this one are developed. The respective data types are likely to be BOOL and UINT. The CLR manages the marshalling of these data types between the managed code and the unmanaged code. Note also that the managed code needs to have the data types defined as managed code data typesthat is, BOOL in C# cannot be used.