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
- :
- BASIC MSI: Clarification of Major and Minor Upgrade Rules
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
Jul 09, 2008
07:59 AM
BASIC MSI: Clarification of Major and Minor Upgrade Rules
Yesterday we encountered an issue that resulted in a minor upgrade failing. In our tests components associated with feature "CORE" were not upgraded.
However, components associated with a feature "Voice Recognition" were upgraded. There was no warning that the upgrade violated any rules. When the user then tries to run the application the Windows Installer self repair tries to run and appears to be in a funny state as it is seeking for files found in the previous release of the product.
In researching this I discovered that five components were deleted from "CORE". These components only included registry entries. The registry entries, as near as I can tell, were consolidated with other components. Therefore the five missing components were not needed.
NOTE - we make use of InstallShield Collaboration and the Developer Information Manifest files, so I do not see these changes coming across my desk immediately.
Now here is the kicker. Apparently it is permissible to delete a feature during a minor upgrade, however, the caveat is that the component is must not be deleted. See the MSDN rules for changing the ProductCode.
So how can you delete a feature without deleting a component associated with the feature? Doesn't this seem like a contradiction?
As best I can see the component must be associated with multiple features, but even then I am not certain.
In my case the components in question were only associated with the "CORE" feature. It seems strange to me that it is possible to delete all file and registry entries from a component but the component itself cannot be deleted in a minor upgrade.
In the mean time I need an effective method to test if a given build violates the minor upgrade rules from a previous release of the product. Is there a way to do this other than creating a patch and running verify?
However, components associated with a feature "Voice Recognition" were upgraded. There was no warning that the upgrade violated any rules. When the user then tries to run the application the Windows Installer self repair tries to run and appears to be in a funny state as it is seeking for files found in the previous release of the product.
In researching this I discovered that five components were deleted from "CORE". These components only included registry entries. The registry entries, as near as I can tell, were consolidated with other components. Therefore the five missing components were not needed.
NOTE - we make use of InstallShield Collaboration and the Developer Information Manifest files, so I do not see these changes coming across my desk immediately.
Now here is the kicker. Apparently it is permissible to delete a feature during a minor upgrade, however, the caveat is that the component is must not be deleted. See the MSDN rules for changing the ProductCode.
So how can you delete a feature without deleting a component associated with the feature? Doesn't this seem like a contradiction?
As best I can see the component must be associated with multiple features, but even then I am not certain.
In my case the components in question were only associated with the "CORE" feature. It seems strange to me that it is possible to delete all file and registry entries from a component but the component itself cannot be deleted in a minor upgrade.
In the mean time I need an effective method to test if a given build violates the minor upgrade rules from a previous release of the product. Is there a way to do this other than creating a patch and running verify?
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jul 09, 2008
02:06 PM
The reason a whole feature can be removed from the installation is because that eliminates all the feature/component registration that MSI maintains about the installation. If you just remove a component from a feature, that breaks the feature/component registration information, causing the feature to become advertised (a component that was previously installed is now missing, therefore the feature is broken and needs to be repaired). Deleting a feature and all its components removes MSI's registration about the feature and the components, so there's nothing left to break.
The Upgrade Validation Wizard should catch removal of components in a minor upgrade with VAL0006.
The Upgrade Validation Wizard should catch removal of components in a minor upgrade with VAL0006.
![](/skins/images/7DF1852B2C95702E61A73F170B191DAC/responsive_peak/images/icon_anonymous_message.png)