Important COM Interop Concepts
Conceptually, developers have two problems to solve. First, they must be able to consume COM objects in their applications, including their Active-X custom controls. Second, they must be able to allow unmanaged COM clients to use the managed .NET objects. Although these steps do not sound all that complicated, it turns out that the COM and .NET worlds are quite different; in order for them to communication with one another, there needs to be some sort of interoperability layer between them. Wrapper is the common term to describe these interop layers. The communication process between the .NET runtime and COM is commonly referred to as COM Interop.
In COM Interop, there are two types of wrappers that you need to deal with—a Runtime Callable Wrapper (RCW) and a COM Callable Wrapper (CCW). The RCW is a wrapper that is callable from the .NET runtime. In essence, the RCW allows applications built on the .NET Framework to consume COM objects. The second type of wrapper, the CCW, enables classes built on the .NET Framework to be available to COM clients through a traditional COM interface. Figure 9.1 shows where these wrappers exist architecturally.
Figure 9.1. Runtime Callable Wrappers and COM Callable Wrappers are the heart of COM Interop, allowing managed and unmanaged applications to seamlessly co-exist.
It helps to review a few definitions before digging into the work of the Runtime Callable Wrapper; remember that applications and components that are built on top of the .NET runtime are commonly called managed applications, whereas all other applications (including anything built with Visual Basic 6.0) are referred to as unmanaged. The job of the RCW is to act as a proxy between managed and unmanaged classes by continually marshalling calls between the two environments. The runtime will use one copy of the RCW for every COM object your .NET classes invoke and is responsible for the actual COM object invocation, adding and releasing COM reference counters as required. When your application creates the RCW, it in turn instantiates the appropriate COM object that it manages. When your application releases the RCW, it will decrease the reference count of the COM object. The COM object will be destroyed once its reference count is equal to zero, signaling that no other application is using it.
The RCW, on the other hand, is managed. This means that even though your COM object may have been physically destroyed, the RCW is subject to garbage collection and can hang around until such a time when it's cleaned up.
COM Callable Wrappers (CCW) allow unmanaged code to call managed code through a COM interface. In essence, CCWs allow you to expose a COM interface for your .NET object, thus providing a proxy between the COM client and your .NET object. The runtime automatically creates one CCW for exactly one managed object regardless of the number of COM clients that request it. The CCW, in turn, holds a single reference to the managed object that implements the interface and is garbage collected. This will allow COM and .NET clients to make requests on the same managed object simultaneously.
CCWs act like traditional COM objects in many important ways:
CCWs are reference-counted like other COM objects, which means they release their references whenever the last client stops using them.
CCWs also have CLSIDs and IIDs just like traditional COM objects.
CCWs, like most COM objects and not like RCWs, are not managed in the same manner as most code you will create from Visual Basic .NET. In order for other COM clients to consume CCWs, these wrapper objects must be created from a non-collected heap and are not subject to garbage collection.
CCWs and RCWs don't quite solve the problem of COM Interop, however. There is still a little problem with data types. One of the great things about applications built on .NET is that they share a common set of data types regardless of the programming language used. For example, the definition of an integer is the same everywhere in the managed environment. This breaks down many barriers when it comes to interacting with other managed objects. In most cases, COM parameters and return values share common data type representations with the managed environment. However, in some cases, COM can present types that are either ambiguous or do not have any equivalent in the managed environment. Because of this, you need something that will help ensure type translations between the COM and .NET applications. The process of packaging parameters and return values into equivalent data types as they move to and from COM objects is called interop marshalling and is no small problem.
The .NET Framework and Visual Studio .NET provide you with a lot of support when it comes to COM Interop. In fact, much of what's described here is implicit in many cases, allowing you to focus on your application's functionality and not on the details of COM Interop. The rest of this chapter shows you how to create RCWs and CCWs and discusses some important considerations for someone about to use COM Interop in their application.