Can my COM client load when the DLL is incompatible?

[Steven Kossow]

My app uses early binding to objects in my server dll, and I want to offer
some graceful exit when there is a version conflict. If for some reason the
end-user gets the wrong version of my COM server dll, I want my client app
to load just long enough to display an error message. Try as I might,
though, if I have an incompatible version of the dll registered, the client
app doesn't load at all, and Windows simply beeps when I try to run it.

Any suggestions on how to verify the component version from within the
application?

[ralph]

Unfortunately that is one of the features of early-binding, your components
are all assembled by the Windows loader and brought into your address space
when the application loads. There is nothing your application can do about
it.

Note: You can see what the loader is going to load by using dumpbin and examine
the dependancies.

One organization that had this problem actually wrote a small exec that utilized
late-binding to examine what components were availble before launching the
main application. (I always felt it was a kludge but it worked.)

Another recourse is by being very careful with your interface changes and
GUID, it is possible to manage different versions that are seen as the same
interface. (Easy with C++, darn interesting to do in VB however.)

You might also re-examine your components and their interfaces. If they are
changing so frequently it may be an indication that maybe they aren't what
you need.

Late-binding gets a lot of bad press because it is slower than early-binding,
but it was designed for just such a situation you just described. Why not
use it?