Background:
I would like to extract the COM data from a VB6 application so I can register it correctly (according to Microsoft best practice) the application. I am using WiX 3.0 and heat.exe will not extract the data (known issue with heat) and I do not have ready access to the associated TLB file. The VB6 application does not have compatibility turned on so it regenerates the COM GUIDs every build (They want to have the application be able to run side by side with an older version.)
I created a C# application that will collect the TypeLib, interface and CoClass information from the VB6 application without registering it and create a wxs file for candle to use. My company has several other older applications like this and I would like to make it a more generic solution.
The Issues:
1.Is there a way to collect the 'true' ProgID (programmer intended one) from the application with out the project or TLB file and without registering it?
2.Is there a way to find out the intended Threading Model from a DLL without registering it? (I intend that it can handle all COM active items, might as well be complete) Thank you.
Yes and no.
As far as I know, there's no generic way to get ProgIDs out of a typelib or COM server.
The entry point for DLLs is
DllRegisterServer
which is supposed to write registration information to the registry, and for EXE servers they usually have a command-line argument that has the same implication.Type libraries happen to contain a description of all interfaces and coclasses in the component, but they rarely contain the human-readable ProgID.
The only clear way I can see and recommend is to override HKCR\CLSID key to point to somewhere temporarily, and then call
DllRegisterServer
. As registry key overrides are process-local this will only work for in-process (DLL) servers.See http://msdn.microsoft.com/en-us/library/ms724901(v=VS.85).aspx for info on overriding registry keys.
Then inspect the scratch registry and see what changes were made, e.g. CLSID<->ProgID mappings, threading model, etc.