Debugging and defensive programming techniques can be used even in postimplementation. We always protect our applications against bad dynamic links (with DLLs and with ActiveX components such as OLE Custom Controls, or OCXs) by using another internal tool.
One of the really great things about Windows is that the dynamic linking mechanism, which links one module into another at run time, is not defined as part of some vendor’s object file format but is instead part of the operating system itself. This means, for example, that it’s really easy to do mixed language programming (whereas with static linking it’s really hard because you’re at the mercy of some vendor’s linker—you just have to hope that it will understand). Unfortunately, this same mechanism can also get you into trouble because it’s not until run time that you can resolve a link. Who knows what you’ll end up linking to in the end—perhaps to an old and buggy version of some OCX. Oops!
By the way, don’t use a GUID to determine the version of any component. The GUID will almost always stay the same unless the object’s interface has changed; it doesn’t change for a bug fix or an upgrade. On the other hand, the object’s version number should change whenever the binary image changes; that is, it should change whenever you build something (such as a bug fix or an interface change) that differs in any way from some previous version. The version number, not the GUID, tells you whether you’re using the latest incarnation of an object or application.
Because it affects your application externally, this kind of versioning problem can be extremely hard to diagnose from afar (or for that matter, from anear)!