COM+ Programming with Visual Basic

Summary

In this chapter, you learned how to version your COM servers. The degree of versioning has to do, to a certain extent, with the type of client you are developing. It is easier to develop for scripting clients because they do not use interfaces directly. That means that you can change your interfaces without breaking existing client code. You can, for example, add optional parameters to methods. You also do not have to worry about versioning settings in your VB project, unless your scripting code uses the <OBJECT> tag with the CLSID property. Then you must ensure that all CLSIDs remain the same.

When vtable-bound clients use your components, you have to be careful that interface definitions do not change. The COM specification says that once an interface has been published, it must not be changed. A change to the interface means that you must change the IID for the interface—in other words, you must rename it.

Visual Basic automatically generates GUIDs for you each time you compile and each time you run your project in the debugger. For this reason, you must tell VB when you wish to keep GUIDs the same and which GUIDs to keep the same. Your options are Binary Compatibility, Project Compatibility, or No Compatibility. If you choose Binary Compatibility, you are telling VB to preserve all GUIDs. Project Compatibility tells VB to preserve only the LIBID and all CLSIDs. No Compatibility tells VB to generate brand new GUIDs for everything.

You learned in this chapter that it is very ...