Extract COM Data from EXE wrong for LaunchPermissions

[osenft]

Hi,

I have an EXE which writes (amongst others) the following COM data to the registry (as defined in RGS files used with VS2005):
[code]
[HKEY_CLASSES_ROOT\AppID\{B72C0551-0B59-4854-8C54-8DBFE73E2777}]
@="KrdmHubLogic"
"ServiceParameters"=""
"LocalService"="KmdmService8"
"LaunchPermission"=hex:01,00,04,80,70,00,00,00,80,00,00,00,00,00,00,00,14,00,\
00,00,02,00,5c,00,04,00,00,00,00,00,18,00,1f,00,00,00,01,02,00,00,00,00,00,\
05,20,00,00,00,20,02,00,00,00,00,14,00,0b,00,00,00,01,01,00,00,00,00,00,01,\
00,00,00,00,00,00,14,00,0b,00,00,00,01,01,00,00,00,00,00,05,04,00,00,00,00,\
00,14,00,0b,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00,01,02,00,00,00,00,\
00,05,20,00,00,00,20,02,00,00,01,02,00,00,00,00,00,05,20,00,00,00,20,02,00,\
00
[/code]

Extracting the COM data using RegSpyUI returns the same data, as expected.

However, using the IS2008 integrated "Extract COM Data for Key File" (where the key file is the same EXE as used in RegSpyUI), I get this:
[code]
[HKEY_CLASSES_ROOT\AppID\{B72C0551-0B59-4854-8C54-8DBFE73E2777}]
@="KrdmHubLogic"
"ServiceParameters"=""
"LocalService"="KmdmService8"
"LaunchPermission"=hex:01,04,70,00,80,00,00,00,14,00,02,5c,04,00,00,18,1f,00,\
01,00,00,00,20,00,20,00,00,14,0b,00,01,00,00,00,00,00,00,14,0b,00,01,00,00,\
00,04,00,00,14,0b,00,01,00,00,00,12,00,01,00,00,00,20,00,20,00,01,00,00,00,\
20,00,20,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00
[/code]

Please note the significant difference in the LaunchPermissions entry ...

I get the same incorrect data when I select "COM Extract at Build = yes".

Is this a know bug? Is there a workaround? We have a lot of EXE files which COM interfaces regularly change at the moment, and I don't want to manually update the information ...

Thank you for any hint
Oskar.

[joshstechnij]

This issue was recently submitted under work order IOC-000063267. The behavior has been resolved in InstallShield 2009.

You could work around this by importing a .reg file into your project that contains the correct binary data.

[osenft]

Hi,

joshstechnij wrote:
This issue was recently submitted under work order IOC-000063267. The behavior has been resolved in InstallShield 2009.

thanks for letting me know! Does this mean there will be a fix for 2008? We only recently (February) bought IS2008 and it has just gone into production now.

I found the update price to 2009 would be again half of the licence cost for 2008. It would be quite annoying if we just bought a broken product ...

You could work around this by importing a .reg file into your project that contains the correct binary data.

Yes, I already found that out. Is it possible to combine automatic COM extraction at build time and a .REG file with the problematic keys? Which of both takes precedence?

Thanks
Oskar.

[joshstechnij]

The work order has been resolved for IS 2009. As far as I know, there are no plans to hotfix this issue.

Regarding ordering of COM extraction and REG import at build, the COM extraction will run first. Then, later in the build, the REG files to be imported are processed on a per-component basis. So you should be able to override the binary data with a .reg file in the REG File To Merge at Build setting on the same component containing the COM server. If this solution fails to work as expected, you can also use self-registration with the EXE instead of COM extraction.

[Qingsong]

Why not?

If it is a problem, then it should be fixed within one year of your product release.

You can not just force the customer to pay extra to buy your hot-fix.:mad:

[osenft]

Hi!

Regarding ordering of COM extraction and REG import at build, the COM extraction will run first. Then, later in the build, the REG files to be imported are processed on a per-component basis. So you should be able to override the binary data with a .reg file in the REG File To Merge at Build setting on the same component containing the COM server.

Great, I'll try that.

If this solution fails to work as expected, you can also use self-registration with the EXE instead of COM extraction.

I'm pretty sure that self-registration is not an option - if we had to rely on that, we wouldn't even need IS and could simply run some scripts ...

joshstechnij wrote:
The work order has been resolved for IS 2009. As far as I know, there are no plans to hotfix this issue.

That's pretty annoying. Who is the right contact to get this resolved? I'd say we can take an upgrade to IS2009 into account, but not for additional $1500. The COM extraction is one of the major features of the IS product. If that's not working properly, I honestly question the sense of even using IS...

Thanks
OSkar.