Unfortunately, this breaks the xcopy install for our .NET software. And introduces unexpected and nasty versioning issues.
Enter reg-free com. This might solve some of these issues. Updating is reduced to copying a new version of the dll, and it even makes possible that different versions of one COM server exist side-by-side (which happened to be the reason behind this technology in the first place).
I record my adventures using registration free COM on this blog for future reference.
VB6 and COM
Step 1 Read the walkthrough.
Step 2 Create the COM and client applications
Step 3 regsvr32 /u sidebyside.dll
And notice that the client exe will now fail.
Step 3 Create manifest files
which hold the information that makes XP find the COM server without the registry.
To know by which GUIDs the component is known, the OLE/COM object viewer is a very nice tool. It can be downloaded from the Microsoft site. The download does not include an essential dll, iviewers.dll, (obviously this has not been tested thoroughly), which can be downloaded from this location. After install, your system has not been polluted with shorcuts to any exe whatsoever, and the program can be found at this intuitive location: "%ProgramFiles%\Resource Kit"
I created a sendto command to drop the dll's onto the exe, which will then show you the information you need.
The "walkthrough" does not walk me through which GUID maps to what attribute in the xml file, but my guessing was right:
/assembly/file/comClass/@clsid maps on the uuid on "coclass SideBySideClass"
/assembly/file/typeLib/@tlbid maps on the uuid on "library SideBySide" (topmost uuid)
/assembly/comInterfaceExternalProxyStub/@iid maps on uuid on "interface _SideBySideClass : IDispatch"
/assembly/comInterfaceExternalProxyStub/@tlbid is the same as /assembly/file/typeLib/@tlbid
Step 4 Start the client exe and celebrate that it works for VB6 exe to COM dll.
Tomorrow: .NET and COM.