Is there a way to convert registry to COM?

[Cygnusx1]

Is there a way to convert registry information from a file (from regspy) into COM registration? In my Basic project, from Repackager, I have several files that contain COM information but were not converted to COM registration. As a matter of fact, the COM parts of the file were not even entered as registry information. If I right-mouse click the file I am not given the option to Extract COM data for key file (or Refresh).

I would hate to spend time manually tediously entering all the COM data.

[Cary_R]

Hi There,

Generally, if you have the file set as the Keypath of its own Component, you should only have to enable "COM Extract at Build".

Now, if this gives an error, and when you right-click the file it has the "Extract COM Data for Key File" option disabled, then the *.dll may not use a standard entrypoint for self-registration. I would take a look with a *.dll export viewer and see at that point.

But, it's probably worth testing it manually with RegSpyUI.exe, which ships in:

C:\Program Files\InstallShield\2010\Support\

[Cygnusx1]

regspy is able to export the data. I would rather do COM extract when file is added so I can see the data rather than check for it later.
But still, is there a way to import the .reg and have it populate the COM tables? As in Wise?

[Cary_R]

Importing from a *.reg file doesn't map to the COM tables, although doing so just pulls into the Registry table.

But, it sounds like you're more interested in Static COM Extraction, which is the aforementioned "Right click -> Extract COM Data for Key File". Basically, you will use this instead of setting COM Extract at Build on the component properties.

This will extract into the COM Tables, you can check it, edit if you like, and any refresh will take place manually.

[Cygnusx1]

that is what I need but that feature is grayed out.
The .dll has COM information as regspy shows.
If using Wise the COM data is placed into the appropriate COM tables.

[Cary_R]

Something sounds amiss if the *.dll works with Regspy, but doesn't have that option when you have it set as a keyfile.

Would it be possible to post the *.dll so I could take a look at it?

[Cygnusx1]

Keep in mind this is all from a setup capture.
If I delete the file from the project and then add it back in then all the COM items are in the correct place; but the component is not suffixed with "_COM".
Rework is time consuming. Do you know of a way that I can avoid this problem?
Some type of configuration between Repakager and Installshield 2010?

[Cygnusx1]

If I run Repackager with before/after snapshot then the ability to Extract or Refresh COM data for the key file is present. The COM data still was not placed in the tables; but I was able to refresh/extract the data. At least this is a step in the right direction.
However, I would still like the COM data to be placed in the appropriate COM tables if I import a .reg.
And while I am at it, why doesn't any of the Type Libraries get imported to the TypeLib Table?

There is something to be said about the simplicity of Wise Package Studio compared to Installshield's inability to these simple tasks.

[Cary_R]

I think we'd definitely like to fix whatever issue you're seeing.

What I would say to do is to post the project file (just the repackager and InstallSHield projects should be fine), and what application you repackaged to generate these setups.

I can take a look and see if there's anything obviously wrong.

[DebbieL]

FYI: Microsoft recommends that you avoid using the TypeLib table. For more information, see http://msdn.microsoft.com/en-us/library/aa372092(VS.85).aspx. That is why InstallShield uses the Registry table instead of the TypeLib table.

[Cygnusx1]

I have used the TypeLib Table for nearly nine years with no problems.
Makes you wonder why there are ICE errors generated on something that is recommended !

Installation package authors are strongly advised against using the TypeLib table. Instead, they should register type libraries by using the Registry table. Reasons for avoiding self registration include:
By "self registration" do they mean the SelfReg table?

[Cary_R]

Yes, the SelfReg or the ISSelfReg table. Or even using a custom action that calls RegSvr32.exe.

[Cygnusx1]

Why not the TypeLib Table? I never use the Selfreg Table always the COM tables.