Clever Geek Handbook

Com dll update

We have an application that uses a COM dll.Now, we are pushing updates to this DLL. We will copy the new dll (overwrite the existing one) and register the dll. This is good practice. Or we must first unregister the dll on the client machine.

0


source to share


5 answers


As long as your old COM DLL implements the same interfaces, there is no reason to unregister / register



+2


source


When updating the COM dll, we should not change the old interfaces, that is, the IID (basic COM rule) so that it does not break clients that use the old interfaces.



This way, there is no need to remove old COM DLLs, just register a new DLL. After registering the new dll, since the old interface uses the same IID, it will not break clients that use the old interface.

+1


source


Two things you need to consider if you just want to replace Com Dll:

  • They both old and new have the same GUID.
  • You haven't added any new interfaces for the updated com Dll.

otherwise you should disable / reg your com dll

0


source


Well, assuming you are writing your COM server using VB6 (a common case a couple of years before), you need to set it to binary compatible so that VB keeps the same GUIDs for that component.

Since objects for classes in DLLs most of the time are created using a factory class embedded in the same DLL, if the GUIDs do not match those that the factory class knows about it, they cannot create objects for the old GUIDs, even if there is no change in there were no interfaces.

This was part of DLL Hell, remember?

0


source


If you know that all client platforms are running Windows XP or later, you might want to consider using Registration Free COM and thus avoid the whole problem.

See my answer to "How do I register COM libraries at runtime?" For details. ... The article Automatically Activating COM Components: A Step-by-Step Guide on MSDN has a complete description of what to do.

0


source






More articles:


All Articles