This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- COM registration via merge module only works for a single feature
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 01, 2009
05:51 PM
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.
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.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 01, 2009
06:29 PM
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Oct 02, 2009
08:36 AM
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.
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.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)