Managed and Unmanaged Code Interoperation

Chapter 15

Managed and Unmanaged Code Interoperation

There can be no question about the need to provide seamless interoperation between managed and unmanaged code, and I’m not going to waste time discussing this obvious point.

Depending on the type and the role of the unmanaged code, managed and unmanaged code can interoperate in several different scenarios. First of all, the unmanaged code participating in the interoperation can be either “traditional” code, exposed as a set of functions, or classic COM code, exposed as a set of COM interfaces. Second, the unmanaged code can play the role of either a server, with the managed code initiating the interaction, or a client, with the unmanaged code initiating the interaction. Third, the unmanaged code can reside in a separate executable, or it can be embedded in the managed module. The embedding option exists only for a “traditional” unmanaged server, and its use is limited to the specifics of the Microsoft Managed C++ (MC++) compiler implementation.

These three dichotomies result in the classification of the interoperation scenarios shown in Figure 15-1.

Figure 15-1 A classification of interoperation scenarios.

We have five basic scenarios here:

• An external COM server, implemented through the COM interoperability subsystem of the common language runtime and runtime callable wrappers (RCW)

• An external COM client, implemented through the same subsystem and COM callable wrappers (CCW)

• An external “traditional” server, implemented through the platform invocation (P/Invoke) subsystem of the runtime

• An embedded “traditional” server, implemented through a special case of P/Invoke known as IJW (“it just works”)

• An external “traditional” client, implemented through the unmanaged export of the managed methods