0
votes

a COM object is registered to the system via a bunch of informaion - stuff like the GUID, ProgId etc. TypeLibs also have a 'version' field which a) can be written to the registry and b) are inside the idl. My question now is - is the version field somehow checked by the system while using/ initating the COM object. E.g. if I create a new version of my COM Object without changeing the GUID but with incrementing the version number does this lead to any kind of inconsistency?

The reason for not changing the GUID but incrementing the version number would be bug fixes in the typelib without touching the interface.

1
Are you planning to run the old and new COM objects side by side in a single process ?MSalters
Nope... The old dlls (so the COM implementation) will be replaced. So in the end there will be only one COM object - the old one will be overwritten.Vegetico
With "COM objects", I meant the ones which are actually created via CoCreateInstance. But you clearly intend to shut down any running client (you can't overwrite a DLL while in use).MSalters
OK, sorry... I'm shutting down my application, so there is no 'runtime side by side'. As mentioned it's maily for bugfixes - so i'd like to increment the version number (because something but not the interface has changed) but not change the GUIDs so the client (the user of the COM) does not have to recompile...Vegetico

1 Answers

0
votes

This should not be an issue, gven your deployment scenario. COM is an umbrella term for a series of technologies. At almost the lowest level*, CoCreateInstance doesn't care about higher-level concepts such as typelibs. It does care about IClassFactory, and in particular its CreateInstance method. Neither the CoGetClassObject function to get IClassFactory, nor the IClassFactory::CreateInstance method use the typelib version number, or even assume that a typelib exists.

*At the very lowest level, you can even have COM objects without a class factory or CLSID, but those can't be created by CoCreateInstance.