1 reply to this topic

[Tyler Curtis]

I'm Using IS-12 and I'm trying to understand what causes merge module order beneath a feature so that I can manipulate it.

In ISWI 2.03, the merge module order could be arranged depending on the sequential order of the modules placed in a feature. This was important to us because we have a number of modules that share a registry setting and the last module entered under a feature would be the last registry entry installed and therefore we could direct which module would be viewed on initial opening of the software.

With IS-12, I can't seem to force the order of modules under a feature upon initial placement of the modules in the project. Furthermore, if a module is removed and then replaced, it returns to the same order which it had previously. The order does not sequentially follow the module ID guid or the package code guid. It does not follow an alphabetic order, either.

Using Orca, I have tried rearranging the order of the registry setting in the components table, feature components table and registry table without success. I also noticed when saving the registry table using Orca, (after moving the desired entry to the end of the list) the desired entry was returned to the sequential module ID guid order. When comparing the module ID guid list in the registry table of the ISWI 2.03 project, the table is not initially sorted that way - in fact it is hard to determine how it is initially sorted.

Does anybody know of a way to manipulate the order of merge modules under a feature?

[Stefan Krueger]

There's no documented way to control the order in which registry entries get written by the Windows Installer engine. While it may have worked, it might change without notice. Also, you shouldn't write to the same registry entry with different components.
Instead: create one component for this shared entry, and attach it to all the features. You can use a proeprty as the regiostry value, and use type 51 (set a property) custom action to set its value appropriately.