- Referencing a COM Component in Visual Studio .NET
- Referencing a COM Component Using Only the .NET Framework SDK
- Example: A Spoken Hello, World Using the Microsoft Speech API
- The Type Library Importer
- Using COM Objects in ASP.NET Pages
- An Introduction to Interop Marshaling
- Common Interactions with COM Objects
- Using ActiveX Controls in .NET Applications
- Deploying a .NET Application That Uses COM
- Example: Using Microsoft Word to Check Spelling
- Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
An Introduction to Interop Marshaling
When calls are made from managed code to unmanaged code (or vice-versa), data passed in parameters needs to be converted from one representation to another. These conversions are described in the next chapter. The process of packaging data to be sent from one entity to another is known as marshaling. In COM, marshaling is done when sending data across context boundaries such as apartments, operating system processes, or computers. (Apartments are discussed in Chapter 6.) To differentiate the marshaling performed by the CLR from COM marshaling, the process of marshaling across unmanaged/managed boundaries is known as Interop marshaling.
COM marshaling often involves extra work for users, such as registering a type library to be used by the standard OLE Automation marshaler or registering your own proxy/stub DLL to handle marshaling for custom interfaces that can't adequately be described in a type library. Interop marshaling, on the other hand, is handled transparently in a way that's usually sufficient by a CLR component known as the Interop Marshaler. The metadata inside an Interop Assembly gives the Interop Marshaler the information it needs to be able to marshal data from .NET to COM and vice-versa.
Interop marshaling is completely independent of COM marshaling. COM marshaling occurs externally to the CLR, just as in the pre-.NET days. If COM marshaling is needed due to a call to a COM component occurring across contexts, Interop marshaling occurs either before or after COM marshaling, depending on the order of data flow. One direction of COM marshaling and Interop marshaling is pictured in Figure 3.10.
){kind=link}
Figure 3.10 The relationship between Interop marshaling and COM marshaling.
In this diagram, a COM component returns a COM string type known as a BSTR to a .NET application calling it. BSTR is a pointer to a length-prefixed Unicode string. The pictured string contains "abc" and has a four-byte length prefix that describes the string as six bytes long. (The extra zeros appear in memory because each Unicode character occupies two bytes.) The calling .NET object happens to be in a different apartment, so standard COM marshaling copies the string to the caller's apartment. See Chapter 6 for controlling what kind of apartment a .NET application runs in when using COM Interoperability.
Once the BSTR has been marshaled by a standard COM mechanism, the Interop Marshaler is responsible for copying the data to a .NET string instance (System.String). Although .NET strings are also Unicode and length-prefixed, they have additional information stored in their prefix. Hence, a copy must be made between these two bitwise-incompatible entities. This new System.String instance can then be returned to the .NET caller (after the Interop Marshaler calls SysFreeString to destroy the BSTR). The CLR and the Interop Marshaler don't know or care that COM marshaling has occurred before it performed Interop Marshaling, as long as the unmanaged data is presented correctly in the current context. If an interface pointer were being passed from one apartment to the next and the interface did not have an appropriate COM marshaler registered for it, the call would fail just as it would in a pure COM scenario.
Many data types, such as strings, require copying from one internal representation to another during an Interop transition. When such data types are used by-reference, the Interop Marshaler provides copy-in/copy-out behavior rather than true by-reference semantics. Several common data types, however, have the same managed and unmanaged memory representations. A data type with the same managed and unmanaged representation is known as blittable. The blittable .NET data types are:
- System.SByte
- System.Int16
- System.Int32
- System.Int64
- System.IntPtr
- System.Byte
- System.UInt16
- System.UInt32
- System.UInt64
- System.UIntPtr
- System.Single
- System.Double
- Structs composed only of the previous types
- C-style arrays whose elements are of the previous types
In version 1.0 of the CLR, the Interop Marshaler pins and directly exposes managed memory to unmanaged code for any blittable types. (Pinning is discussed in Chapter 6.) By taking advantage of a common memory representation, the Interop Marshaler copies data only when necessary and therefore exhibits better performance when blittable types are used. This implementation detail can show up in more ways than performance, however. For example, copying data in or out of an Interop call can be suppressed by custom attributes, but for blittable types these same custom attributes have no effect because the original memory is always directly exposed to the method being called. Chapter 12, "Customizing COM's View of .NET Components," discusses these custom attributes and their relationship to blittable data types.
You can customize the behavior of the Interop Marshaler in two ways:
-
Changing the metadata inside Interop Assemblies to change the way the Interop Marshaler treats data types. This technique is covered in Chapter 6.
-
Plugging in your own custom marshaler, as discussed in Chapter 20, "Custom Marshaling."