COM ABC

All calls made between managedand unmanaged code must negotiate the requirements imposed by each respectiveprogramming model. Managed and unmanaged programming models are dissimilar inmany respects. The following table shows the defining characteristics of eachmodel.

Characteristic	Unmanaged model	Managed model
Coding model	Interface-based	Object-based
Identity	GUIDs	Strong names
Error handling mechanism	HRESULTs	Exceptions
Type compatibility	Binary standard	Type standard
Type definition	Type library	Metadata
Type safety	Not type safe	Optionally safe
Versioning	Immutable	Resilient

Some programming model characteristics have associated entitiesthat you can view, such as type libraries and metadata. Some you can pass asarguments, such as Globally Unique Identifiers (GUIDs) and strong names. Othercharacteristics are more conceptual: you will undoubtedly consider their impacton your application design, but you will not encounter direct mapping betweenthe managed and unmanaged models for these characteristics.

The following sections explain each characteristic in more detail.

Coding models

Unmanaged objects always communicate through interfaces; managedobjects and classes can pass data directly without implementing interfaces.

By default, COM interop generates a class interface to exposemanaged functionality through an interface to COM when the object or class doesnot implement one.

Error handling mechanisms

COM methods usually return an HRESULT, indicating that the callsucceeded or failed. Managed code incorporates exceptions. By default, COM interopmaps managed exceptions to failure HRESULTs.

Identities

GUIDs identify a specific unmanaged type and provide no locationinformation for that type. Strong names consist of a unique assembly name inaddition to a type name. Because the assembly name uniquely identifies thetype, you can reuse a type name across multiple assemblies. An assembly alsointroduces publisher key, version, and location information to a managed type.Interoperation services generate GUIDs and are strong-named as required.

Type compatibility

Types vary between managed and unmanaged code, and also amonglanguages.

Type definitions

If you are accustomed to working with type libraries, you knowthat they contain only public types. Moreover, a type library is optional. Inthe managed programming model, type information is mandatory for all types.Interoperation services provide tools that convert type libraries to metadatain assemblies and metadata to type libraries.

Type safety

Unmanaged compilers provide no type checking on pointer types,making the code susceptible to potentially harmful activity. In general,managed code requires a higher level of trust. Programmers can continue to usepointers in managed code, although the code has restrictions due to its unsafebehavior. Interoperation services prevent untrusted, managed code fromaccessing unmanaged code.

Versioning

COM interfaces are immutable. If you change an interface, you mustrename it with a new GUID. Managed types can evolve, keeping the same name.

 

 

 

The common language runtime exposes COM objects through a proxycalled the runtime callable wrapper (RCW). Although the RCW appears to be anordinary object to .NET clients, its primary function is to marshal callsbetween a .NET client and a COM object.

The runtime creates exactly one RCW for each COM object,regardless of the number of references that exist on that object. The runtimemaintains a single RCW per process for each object. If you create an RCW in oneapplication domain or apartment, and then pass a reference to anotherapplication domain or apartment, a proxy to the first object will be used. Asthe following illustration shows, any number of managed clients can hold areference to the COM objects that expose INew and INewer interfaces.

Accessing COM objects throughthe runtime callable wrapper

Using metadata derived from a type library, the runtime creates boththe COM object being called and a wrapper for that object. Each RCW maintains acache of interface pointers on the COM object it wraps and releases itsreference on the COM object when the RCW is no longer needed. The runtimeperforms garbage collection on the RCW.

Among other activities, the RCW marshals data between managed andunmanaged code, on behalf of the wrapped object. Specifically, the RCW providesmarshaling for method arguments and method return values whenever the clientand server have different representations of the data passed between them.

The standard wrapper enforces built-in marshaling rules. Forexample, when a .NET client passes a String type as part of an argument to anunmanaged object, the wrapper converts the string to a BSTR type. Should theCOM object return a BSTR to its managed caller, the caller receives a String.Both the client and the server send and receive data that is familiar to them.Other types require no conversion. For instance, a standard wrapper will alwayspass a 4-byte integer between managed and unmanaged code without converting thetype.

 

 

 

The primary goal of the runtimecallable wrapper (RCW) is to hide the differences between the managed andunmanaged programming models. To create a seamless transition, the RCW consumesselected COM interfaces without exposing them to the .NET client, as shown inthe following illustration.

COM interfaces and theruntime callable wrapper

When created as an early-bound object, the RCW is a specific type.It implements the interfaces that the COM object implements and exposes themethods, properties, and events from the object's interfaces. In theillustration, the RCW exposes the INew interface but consumes the IUnknownand IDispatch interfaces. Further, the RCW exposes all members of theINew interface to the .NET client.

The RCW consumes the interfaces listed in the following table,which are exposed by the object it wraps.

Interface	Description
IDispatch	For late binding to COM objects through reflection.
IErrorInfo	Provides a textual description of the error, its source, a Help file, Help context, and the GUID of the interface that defined the error (always GUID_NULL for .NET classes).
IProvideClassInfo	If the COM object being wrapped implements IProvideClassInfo, the RCW extracts the type information from this interface to provide better type identity.
IUnknown	For object identity, type coercion, and lifetime management: ·         Object identity The runtime distinguishes between COM objects by comparing the value of the IUnknown interface for each object. ·         Type coercion The RCW recognizes the dynamic type discovery performed by the QueryInterface method. ·         Lifetime management Using the QueryInterface method, the RCW gets and holds a reference to an unmanaged object until the runtime performs garbage collection on the wrapper, which releases the unmanaged object.

The RCW optionally consumes the interfaces listed in the followingtable, which are exposed by the object it wraps.

Interface	Description
IConnectionPoint and IConnectionPointContainer	The RCW converts objects that expose the connection-point event style to delegate-based events.
IDispatchEx	If the class implements IDispatchEx, the RCW implements IExpando. The IDispatchEx interface is an extension of the IDispatch interface that, unlike IDispatch, enables enumeration, addition, deletion, and case-sensitive calling of members.
IEnumVARIANT	Enables COM types that support enumerations to be treated as collections.