Supporting our Lifecycle Policy with ARPSYSTEMCOMPONENT
To conclude the series of the problems with ARPSYSTEMCOMPONENT, we will extend the workaround to support setting ARPSYSTEMCOMPONENT=1 to support Microsoft’s lifecycle policy on support N and N-1, where N would be a service pack, and N-1 would be the previous service pack or the RTM.
Since we’ve essentially already developed our own sequencing feature in order to keep patches in view at all times, we must also take care of removing those patches’ Add/Remove Program (ARP) registry entries when a patch is effectively superseded by a successive patch or service pack. We did that by defining unique properties for each patch and conditions that are also unique to each patch’s ARP component that successive patches can set to cause the transitive component condition to evaluate to true. It’s essentially the same idea as obsolescence — the method by which patches removed other patches from view before the more robust sequencing feature was added in Windows Installer 3.0. That works fine as long as the patch obsolescence chain of package codes is known at patch build time. To support N-1, however, patch package codes are not always known.
If a service pack is released, it would typically supersede all patches that target the previous service pack or the RTM. N-1 patches, however, are produced after that service pack is released to QA for testing and eventual RTM. The service pack couldn’t know about N-1 patches because they don’t yet exist. Under normal circumstances, that wouldn’t be a problem because the patch transforms would target a specific ProductVersion, a service packs — minor updates — would change that ProductVersion thus removing the patch from the view. Remember, though, that in order to control the addition and removal of our transitive components for ARP we changed the transforms so that they would always apply.
We need to adjust our conditions for the transitive components, then. Currently, the condition would be something like NOT KB001.Replaced, where KB001 is our unique identifying property defined by the patch. A superseding patch would define KB001.Replaced, thus causing the transitive condition for the superseded patch to evaluate to false. Since we know that service packs are to change the ProductVersion property, we can change the condition for small updates to NOT KB001.Replaced OR ProductVersion = 1.0.0 or whatever version is suitable for the actual target of a small update. Minor updates should target the ProductVersion that is the final version after the service pack is applied, like NOT KB005.Replaced OR ProductVersion = 1.1.0. This also means that a service pack — which after several released service pack level would potentially define many replacement properties (ex: KB001.Replaced) — would not need to list all patches it replaced because it will change the ProductVersion and will cause the previous patches — even the N-1 patches — to be effectively superseded.
Thus concludes the series of the perils, necessity, and workaround for defining ARPSYSTEMCOMPONENT=1 for your product while supporting ARP registry keys for patches.
Light
Dark
0 comments