tags:

views:

164

answers:

5

We have an application which uses COM dll.Now, we are pushing updates of this dll.We copy the new dll ( overwriting the existing one) and register the dll. Is this a good practice.Or, should we first unregister the dll already on clients machine.

+2  A: 

As long as your old COM dll implements the exact same interfaces, there's no reason to unregister/register

Paul Betts
A: 

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

  1. They old and new have the same GUID.
  2. You haven't append any new interfaces to the updated com Dll.

otherwise you should unreg/reg your com dll

Mohammed Nasman
+1  A: 

While updating the COM dll, we should not change the old interfaces i.e., IIDs (basic rule of the COM) so that it won't break the clients which are using the old interfaces.

So there is no need to un reg the old COM dll, just register the new DLL. Upon registering the new dll, as old interface uses same IID, it will not going to break the clients which are using the old interface.

Vinay
A: 

Well, supposing you're writting your COM server using VB6 (a common case a couple of years before) you'll need to set it binary compatible to make VB keep same GUIDs for the component.

As the objects for the classes in the DLLs most of the time are being created using the class factory built into the same dll, if GUIDs not match with the ones the Class Factory knows about it cannot create objects for the old GUIDs even if no changes were made to Interfaces.

That was a part of the DLL Hell, remember?

Eugenio Miró
A: 

If you know all your client platforms are running Windows XP or later, you might consider using Registration Free COM, and thereby avoid the entire issue.

See my answer to "How to register COM libraries at runtime?" for details. The article "Registration-Free Activation of COM Components: A Walkthrough" on MSDN has a complete walkthrough of what to do.

Tim Farley