@For PDFFORGE team:
I am a developer of a Microsoft .Net 3.5 application, where I referenced the PDFCreator COM-Component. By this, an Interop.PDFCreator.dll is created by the development environment. This contains the CLSID-s of the classes in the PDFCreator COM-component.
But every time when a new PDFCreator version is released, the CLSID-s are changed, and the previous Interop.PDFCreator.dll is invalidated. When the users of my application installs the new release of PDFCreator, my application starts malfunctioning because of the following InvalidCastException:
Unable to cast COM object of type 'PDFCreator.clsPDFCreatorClass' to interface type 'PDFCreator._clsPDFCreator'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{DEA7C7BD-D84B-42DD-BF5E-C201DB5A9143}' failed due to the following error: This object interface is not supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).
By this, my application (and, of course, me) is blamed because of the issue. :(
Question: why the CLSID-s of PDFCreator cannot be backward compatible?
@Hint For PDFFORGE team:
It seems PDFCreator.exe depends on MSVBVM60.dll, so I suppose it is developed in VB6. To have CLSID-s backward compatible, please open your VB6 project’s Properties dialog, choose the "Component" tab, and select "Binary Compatibility" in "Version Compatibility" frame, and choose an older PDFCreator.exe. Next time, when a new PDFCreator.exe is made, the old CLSID-s are copied/used from the old exe. Whenever you add or modify a MultiUse class (Public for COM) in the project, you have to make a new exe, and replace the old (compatibility) exe with the new one. Same goes for ActiveX dll-s in VB6.
Thanks a lot!