views:

34

answers:

2

A change needs to be made in a DLL. The DLL was originally coded in VB6 (not by me), and the source code lost.

It is very simple in its functionality, so I recreated it from scratch, but I only have access to VB Express 2008.

I created it first as a normal DLL then realized it had to be a COM DLL. Fortunately, an excellent article at http://www.codeproject.com/KB/COM/nettocom.aspx tells me how.

But, I don't know anything about GUIDs...

Should I use the same GUID as the original DLL or not? Does it make any difference?


Edit: Does it really matter since it's a COM DLL? It is called into by an Active X control & I can see no reference in the web page to the GUI ... (but I'm just a n00b, so what do I know? ;-)

+2  A: 

If you want this library to be a direct replacement of the original and it is fully binary compatible (all interfaces are unchanged) - then yes, you should use the same GUIDs for the class ids and interface ids. If you don't do that users of the original library will not be able to use yours without recompiling their programs.

Beware that binary compatibility is a must for reusing the GUIDs. If you break any interface - change its id and the id of the class implementing it and recompile the client.

sharptooth
Mawg
@mawg: Well, ActiveX controls differ slightly, but not in how you use GUIDs.
sharptooth
+1  A: 

The GUIDs acts as a kind of identifier for your COM object and DLL. If you use the same GUID you need to register your new DLL so that the location is updated (i.e. if you don't place it exactly in the same spot and have recreated all interfaces the old DLL previously had registered).

The cleaner approach is to generate a new GUID and modify the caller to use the new GUID/DLL instead.

Anders K.
Mawg