GOTCHA 73 Simply tur ning the switch for COM interop is dangerous

GOTCHA #73 Simply tur ning the switch for COM interop is dangerous

Checking the project setting Register for COM Interop prepares your assembly for COM interoperability. When your code is compiled, Visual Studio invokes regasm to place the codebase enTRy details for the assembly into the Registry at HKEY_CLASSES_ROOT\CLSID\...\InprocServer32. When things are that easy, you probably wonder "what's the catch?" There are several things to ponder. First, consider some of the .NET capabilities that are not quite supported in COM, or must not be used with COM:

• COM doesn't support method overloading.

• COM doesn't handle static variables well.

• CoCreateInstance() expects a no-parameter constructor.

• You may not intend to expose all of your public classes for COM interoperability (the COMVisible attribute affects this) .

• It is better to define a GUID for the classes you wish to expose.

• It is better to expose functionality through interfaces instead of classes.

Say you are working on your code one afternoon and someone walks in saying, "Hey I need to access this class through COM, can I?" You say "Sure, all I need to do is turn on the settings to register the assembly for COM interop." This will result in the COM clients talking to your assembly in the manner shown in Figure 8-18.

Figure 8-18. Improperly exposing an assembly for COM Interop

Ask the questions:

• Do you want every public class in your assembly to be visible for COM interop?

• Do you want to control which methods of your class are available for COM clients?

• Should you rethink what the COM client wants to do with your assembly?

• Should you provide a more coarsely grained object for COM clients to interact with? That is, should you provide one class with the functionality the COM client actually needs, rather than just exposing a number of your .NET classes?

Most likely, you wrote your assembly with .NET clients in mind. When you are approached with a request to expose your classes for COM interoperability, it may be better to write a separate façade assembly that the COM client will interact with, as shown in Figure 8-19.

You provide a wrapper or façade that takes requests from COM clients and routes them to one or more .NET classes. The wrapper classes do not expose any COM interfaces directly to the COM client; instead they implement .NET interfaces that are available and accessible to those clients (see Gotcha #72, "All but one of the ClassInterface options are ineffective").

Why should you do this? The wrapper or façade approach gives you a number of advantages:

• You can control what a COM client actually sees.

• You don't expose all public classes in your assembly.

• The façade is written with interoperability in mind and hence is more cohesive.

Figure 8-19. Exposing .NET components for COM interop using Wrappers

• It is easier to deal with changes from the COM client point of view.

• Over time, if applications that use COM are upgraded to use .NET, this is easier to managethe wrapper simply goes away without affecting anything else.

IN A NUTSHELL

Do not open up an assembly for arbitrary COM access. Instead provide a façade for the COM clients to interact through.

SEE ALSO

Gotcha #71, "Auto-generating GUID for your classes leads to versioning woes" and Gotcha #72, "All but one of the ClassInterface options are ineffective."