Even Installing Correctly Does Not Always Work

Even if you follow all the preceding steps and install everything 100 percent correctly, you can still have problems caused by updating components. Why? Well, even though the new component is installed correctly, its behavior might be different enough from the old component that it breaks existing programs. Here is an example. The specification for a function says that a particular parameter must not be NULL, but the old version of the component ran fine if you passed NULL. If you enforce the spec in a new version (you might need to do this to make the component more robust), any code that passes NULL fails. Because not all programmers read the API documentation each time they write a call, this is a likely scenario.

It is also possible for a new version to introduce a bug that you simply didn't catch in regression testing. It is even possible for clients to break as a result of purely internal improvements if they were relying on the old behavior. Typically, we assume that nothing will break when we update a component. In fact, according to Craig Wittenberg, one of the developers of COM who now works in the ComApps group at Microsoft, if you don't have a plan for versioning your components in future releases, it is a major red flag for any component development project. In other words, before you ship Version 1, you need to have a plan for how you will update Version 1.1, Version 2, and beyond besides how to bug-fix your updates.

In the past, it has been common to share components by default and update them whenever needed. This approach has caused many problems with system stability, although it has been efficient in terms of memory and disk usage. Clearly, a less chaotic set of guidelines is needed. With disk and memory so inexpensive today, a growing number of people argue that applications should never share non-system component files, that the stability costs of sharing far outweigh the storage and performance benefits of sharing. This does not mean that you shouldn't use components; it just means that you should allow each application to use the version of the component it was tested with. By not sharing the component files while using components, you get almost all the benefits of component development without destabilizing your users' systems.

Sometimes it is appropriate to share component files, such as the Office DLL (MSOFFICE.DLL). If you do decide to share component files among applications, make sure all the users of the shared component files understand the versioning plan. And never write such components to system directories.