cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jdykstra
Level 3

COM registration via merge module only works for a single feature

In my setup, I have two installshield projects:
1. A merge module that contains a number of files commonly used. Lots of these files also include COM information, which is being extracted at build.
2. An installer that has three features. One feature only installs sample data, and the other two features each install an application. Both applications rely on a common subset of files, which is why the merge module is being produced in step 1. The merge module is associated with two of the three features.

Installshield allows a merge module to be associated with multiple features…no problem there. However, upon running the resulting .msi installer, I noticed COM registration is only happening when a specific feature is selected.

I’ve discovered that internally in the .msm, (using Orca or Installshield direct edit mode) the Class table contains lots of great entries—all good stuff. Strangely, the .msi spec has both a “component” and “feature” column in this class table. I find that a bit odd, because the feature FeatureComponents creates this relationship. Anywho, in the .msm, the component column has foreign keys to the components table, but the feature column is full of Zero values: “{00000000-0000-0000-0000-000000000000}” According to the spec, the feature column is not nullable.

When the .msm containing COM information is tied to more than one feature in an installshield basic .msi project and compiled, the resulting .msi has a Class table with all of the expected data, except the feature column is now filled out—but even though the merge module is associated with more than one feature, the alphabetically first feature name is used in this column. Records only exist for this alphabetically first feature—no records exist in this table for the other features.

As a result, when the installer is run, COM servers are only registered if that alphabetically first feature is selected! If the alphabetically second feature is selected, the installation runs successfully, copies all of the common libraries (from the msm) but doesn’t register them. Of course, in this use-case, the applications cannot run.
Labels (1)
0 Kudos
(2) Replies
jdykstra
Level 3

I made myself a little test .ism file, and when I take merge modules out of the picture and simply use a shared component, installshield reports warning: 7101.

Also, from this page, it looks like acresso's view is this simply is unsupported.
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q105681&sliceId=

That leaves two questions...

1. Why can't installshield simply create n x m rows in the Class table? For each class, create one row per component per feature. I created a simple app and hand-edited the table to achieve this, and it didn't complain.

2. Can I simply bypass the Class table and create entries in the registry table instead? 1b. Is there any automated way to do this?
0 Kudos
KathyMorey
Level 10

This is a known issue with those tables in the MSI - I ran into the same thing a couple years ago.

You might try creating a fourth feature to install the common files. Make sure that feature is installed with either of the two applications. Then the COM table entries will properly reflect a single feature and you'll be okay installing either application.
0 Kudos