Chapter 8: A Simple COM Example

By now, you know how to create COM component application types. This chapter begins your journey into COM+ application development. Well experiment with several techniques for developing COM+ applications. The journey is worth the effort, because youll find that some techniques work better than others do.

After a brief explanation of the importance of GUIDs, the chapter explains how to create a component using the three techniques described in Chapter 5. After you create the component, youll learn two ways to register it on the server. Exporting the server application as a proxy comes next . The client creation steps and testing procedure are the last two tasks well perform. In short, by the time you finish this chapter, youll know a lot more about how COM+ applications work when youre using a managed component and an unmanaged client. (Well explore other component and client scenarios in Chapter 9.)

The Importance of Using GUIDs

In Chapter 5, we discussed three techniques for creating managed components that you can use within COM+: simple, derived from the Component class, and derived from the ServicedComponent class. Before we begin creating components, however, well look at an important housekeeping issue for COM+ components. This section helps you understand the necessity of always using the [Guid] attribute with components designed for use with COM+.

Using .NET components that lack the [Guid] attribute with COM+ could create a mess you never dreamed possible in the registry. A Globally Unique Identifier (GUID) provides a method for unmanaged applications to identify your component, as discussed in Chapters 3 and 4. The GUID must remain the same if you want to use any calls that rely on the GUID to instantiate the component. Therefore, the first reason to use the [Guid] attribute is to ensure you can document the GUID for unmanaged application calls that require it.

However, the importance of using the [Guid] attribute doesnt end with simple identification. Another reason to use the [Guid] attribute is to keep your development machine reasonably clean. Every time you register a component, the registration application makes entries in the registry. If you dont assign a GUID to the component, the common language runtime will automatically select a new GUID for you each time. The CLR assigns this GUID randomly , and the GUID wont be the same from registration to registration.

Theoretically, unregistering the component removes the registry entry, but experience shows otherwise . In some cases, developers have ended up with dozens of entries for the same component in the registry, all of which required manual removal. Trying to find all the entries for a complex component is time consuming and error prone. Eventually, the developer will end up formatting the drive and starting from scratch.

COM+ also requires the [Guid] attribute for another reason. Imagine that youre using servers in a cluster and that each server has a copy of your component installed on it. If the component doesnt use the [Guid] attribute, each server could have a registry entry for the component under a different GUID, which effectively means that each server has a unique version of your component. This little problem makes it impossible for load balancing to work properly because COM will view each component as being different. In sum, even though every server has a copy of the same component, load balancing will see only one copy of the component on one server and wont work as intended.