Exposing .NET Components as COM Objects

I l @ ve RuBoard

Exposing .NET Components as COM Objects

Just as Managed clients can consume class COM objects, the ability to create a COM Callable Wrapper (CCW) also exists. Chances are that the need to create .NET components and expose them as COM objects probably shouldn't come up in general development. As such, I will merely present how to register a .NET component as a COM object and the caveats associated with doing so.

RegAsm.exe

The .NET SDK provides a RegAsm.exe tool that is used to create the necessary entries with the system registry. RegAsm can also generate a type library, .tlb file, to describe the types within the assembly. The Registry entries look like those of a COM object and allow for the loading of the Managed assembly. In addition to using RegAsm.exe to register the Managed assembly, it is also necessary to add the assembly to the GAC , or Global Assembly Cache. The gacutil.exe can be used to accomplish this task.

COM Callable Wrapper

The counter part to an RCW is the COM Callable Wrapper (CCW). Like the RCW, the CCW handles many of the same issues, such as preserving object identity, lifetime management, and so on. The CCW is also responsible for providing interfaces, such as IDispatch and IUnknown , because these interfaces are not part of the managed component. The IDispatch interface allows for scripting clients to make use of Managed components, just as they would use any other IDispatch COM object. Figure 5.3.3 depicts a basic view of the CCW.

Figure 5.3.3. Conceptual view of CCW.

graphics/0503fig03.gif

A CCW acts as a proxy between the COM client and the Managed component.

.NET to COM Issues

COM has very strict rules that govern its implementation. To make effective use of exposing a .NET component to COM, the rules of COM must be followed. Consider the following .NET class:

 1: class Foo { 2:     public Foo( string s ) { ...} 3:     public static void Bar( ) { ...} 4: } 

An attempt to export class Foo to COM would not be successful for two reasons:

  • COM does not support constructors with parameters

  • COM does not have a notion of non-instance methods, such as static methods

Class Foo is considered non-COM friendly. Parameterized constructors should be removed and some initialization method should then be supplied. It is this type of detail that must be adhered to effectively expose Managed objects to COM.

COM supports the notion of value types, just as .NET does. In COM, however, value types cannot have instance methods as they can in .NET and even C++.

 1: public struct Point { 2:     int x; 3:     int y; 4:     void SetXY( int x, int y ) { ...} 5: } 

When the value type Point is exported to COM, the instance method SetXY will be removed and, because members x and y are private, the Point value type will be of no value.

Before embarking on a project to create .NET components with the intention of exposing them to COM clients, be sure that the implementations of those objects follow the rules of COM.

.NET COM Attributes

Along with the basics of exposing a Managed class as a classic COM object, several Attributes exist that allow for finer control of exactly what and how elements are exposed. In addition, it is also possible to declare user code that should be executed during object registration and un-registration using ComRegisterFunctionAttribute and ComUnregisterFunctionAttribute respectively (see Listing 5.3.11).

Listing 5.3.11 .NET COM Attributes Object Registration
 1: using system; 2: public class MyClass { 3:     [ComRegisterFunctionAttribute] 4:     public static void RegisterMethod( Type T ) { ...} 5: 6:     [ComUnregisterFunctionAttribute] 7:     public static void UnregisterMethod( Type T ) { ...} 8: } 9: 

The methods RegisterMethod and UnregisterMethod must be public and static. Also, the Type T parameter is the object type that is currently being registered/unregistered. Remember that attributes can be restricted to classes, interfaces, methods, parameters, return types, and even fields. In the case of ComRegisterFunctionAttributes and ComUnregisterFunctionAttributes , these attributes can only be applied to methods.

Supporting scripting clients requires an IDispatch interface. Using the ClassInterfaceAttribute controls the interface type generated for the Managed class. This can be designated as Dual , IUnknown -derived, or IDispatch only, depending on the requirements of the consuming client. The InterfaceTypeAttribute controls a similar concept only applied to Managed interfaces.

In addition, the ability to specify the ProgID , ProgIdAttribute , and the Guid ( GuidAttribute) , allows for even more control over how the exposed object is perceived. Using the GuidAttribute allows for a Managed class to implement a COM-based interface that can be consumed by a COM client.

I l @ ve RuBoard


C# and the .NET Framework. The C++ Perspective
C# and the .NET Framework
ISBN: 067232153X
EAN: 2147483647
Year: 2001
Pages: 204

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net