Adding MSMs creates new custom actions, extra table entries and ICE82 errors

[QBoy123]

Hi, first post so be kind.

found that when adding certain merge modules to an ISM and then building an MSI, the MSI has new type51 custom actions created with the Module ID of the merge modules appended to the action name, new entries for these actions are created in some sequence tables, but all with the same sequence number,1 (causing the ICE82 error) - what strange's about this is neither the custom actions or new sequence table entries are not in either the ISM or MSMs.

for example, the 'custom action' and 'AdvtExecuteSequence' table for the MSI might contain action 'SystemFolder.25A8526A_636E_4FEA_80CA_4F91F5035F00' but the original ISM and the merge module did not contain any entries in either table. I've been able to replicate this using COMCAT, COMCTL32 and OLEAUT32 merge modules. Importing the same merge modules into an MSI via another packaging tools give the expected results (no ICE82 errors)

Anyone come across this? Thanks in advance for any help.

[HennoKeers]

QBoy123 wrote:
Hi, first post so be kind.

found that when adding certain merge modules to an ISM and then building an MSI, the MSI has new type51 custom actions created with the Module ID of the merge modules appended to the action name, new entries for these actions are created in some sequence tables, but all with the same sequence number,1 (causing the ICE82 error) - what strange's about this is neither the custom actions or new sequence table entries are not in either the ISM or MSMs.

for example, the 'custom action' and 'AdvtExecuteSequence' table for the MSI might contain action 'SystemFolder.25A8526A_636E_4FEA_80CA_4F91F5035F00' but the original ISM and the merge module did not contain any entries in either table. I've been able to replicate this using COMCAT, COMCTL32 and OLEAUT32 merge modules. Importing the same merge modules into an MSI via another packaging tools give the expected results (no ICE82 errors)

Anyone come across this? Thanks in advance for any help.

Most vendor merge modules have a reputation of being crappy (just like vendor MSI's, really) so we have a common pratice to clean them up or create them our own...

regards, Henno.

[QBoy123]

HennoKeers wrote:
Most vendor merge modules have a reputation of being crappy (just like vendor MSI's, really) so we have a common pratice to clean them up or create them our own...

regards, Henno.

Hi, think I need to clarify:

Neither the merge modules or ISM contained any Type51 custom actions.

the extra custom actions and sequence table entries are not in the merge modules or ISM (so dont think its a normal MSM clean up issue), but during compile process extra custom actions and related sequence table action entries are created and can be found in the resultant MSI (with the moduleID of MSM appended to name). This is only happening with Admin Studio, not when the same merge modules are included in an MSI via another packaging tool. Also found that adding the merge module directly to MSI using Admin Studio gives the same results.

This does not happen with all MSMs, are there any know issues which affect Admin Studio's use of MSM?

Using 8.02, is this a bug? Anyone else come across it?
Cheers
Q

[QBoy123]

QBoy123 wrote:
Hi, think I need to clarify:

Neither the merge modules or ISM contained any Type51 custom actions.

the extra custom actions and sequence table entries are not in the merge modules or ISM (so dont think its a normal MSM clean up issue), but during compile process extra custom actions and related sequence table action entries are created and can be found in the resultant MSI (with the moduleID of MSM appended to name). This is only happening with Admin Studio, not when the same merge modules are included in an MSI via another packaging tool. Also found that adding the merge module directly to MSI using Admin Studio gives the same results.

This does not happen with all MSMs, are there any know issues which affect Admin Studio's use of MSM?

Using 8.02, is this a bug? Anyone else come across it?
Cheers
Q

Looks like this is a bug, Macrovision have had a look.
cheers
Q