Just when you thought the series on ARPSYSTEMCOMPONENT was over, I present to you an improved plan for supporting custom supersedence so that you can ship effectively superseded patches and still support N-1 patches, which are patches that apply to the RTM or a previous Service Pack, but are produced after the SP that should supersede them and all other patches that target the RTM or previous SPs.
Previously a separate feature was used for each patch but this forced us to add that to ADDLOCAL via a custom action so users didn’t have to specify that and run some standard actions, then do something similar to set REINSTALL. Calling these standard actions again caused state problems so a simpler solution was necessary.
We made sure that a single feature was added to each RTM we service and now just add new, transitive components to that feature so that Windows Installer knows to automatically reinstall that feature. We still need a simple type 51 custom action to set the REINSTALL property for Windows 98 and Me, since Windows Installer 2.0 is the latest version supported and does not update the feature list to be reinstalled automatically like Windows Installer 3.0 started doing. This custom action should be conditioned only to run on 9x using the Version9X property. During patch build we keep track of what features were updated and put this feature list as a comma-delimited list into the Property table with a unique, patch-specific name. Then all we have to do is set the REINSTALL property using that type 51 custom action to that list. Fortunately in this case Windows Installer 2.0 doesn’t support installing multiple patches at once so we don’t have to concatenate the feature lists.
The components must still be transitive components and you cannot set the supersedence bit because if the components are removed from the view, the selection manager sets the component’s parent feature state to INSTALLSTATE_ADVERTISED and the feature would not be removed during product uninstall. Transitive components’ states are changed to INSTALLSTATE_NOTUSED when disabled because the condition in the Component table evaluates to false.
Since we don’t have to worry about reinstalling new features we can now reset transforms back to targeting a single, specific ProductVersion property and now QFEs are sequenced correctly in the correct buckets for the RTM and for each SP. Transitive components are enabled and disabled correctly using the custom properties and transitive component conditions we defined before, and QFEs and SPs are sequenced correctly.
0 comments