{"id":2943,"date":"2005-08-29T09:19:00","date_gmt":"2005-08-29T09:19:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/heaths\/2005\/08\/29\/supporting-our-lifecycle-policy-with-arpsystemcomponent\/"},"modified":"2005-08-29T09:19:00","modified_gmt":"2005-08-29T09:19:00","slug":"supporting-our-lifecycle-policy-with-arpsystemcomponent","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/setup\/supporting-our-lifecycle-policy-with-arpsystemcomponent\/","title":{"rendered":"Supporting our Lifecycle Policy with ARPSYSTEMCOMPONENT"},"content":{"rendered":"<p>To conclude the series of the problems with <a href=\"http:\/\/msdn.microsoft.com\/library\/en-us\/msi\/setup\/arpsystemcomponent.asp\"><code>ARPSYSTEMCOMPONENT<\/code><\/a>, we will extend the workaround to support setting <code>ARPSYSTEMCOMPONENT=1<\/code> to support Microsoft&#8217;s <a href=\"http:\/\/support.microsoft.com\/gp\/lifepolicy\">lifecycle policy<\/a> 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.<\/p>\n<p>Since we&#8217;ve essentially already <a href=\"http:\/\/blogs.msdn.com\/heaths\/archive\/2005\/08\/26\/456915.aspx\">developed<\/a> our own sequencing feature in order to keep patches in view at all times, we must also take care of removing those patches&#8217; 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&#8217;s ARP component that successive patches can set to cause the transitive component condition to evaluate to true. It&#8217;s essentially the same idea as obsolescence &mdash; the method by which patches removed other patches from view before the more robust <a href=\"http:\/\/msdn.microsoft.com\/library\/en-us\/msi\/setup\/sequencing_patches.asp\">sequencing feature<\/a> was added in <a href=\"http:\/\/msdn.microsoft.com\/library\/en-us\/msi\/setup\/what_s_new_in_windows_installer_version_3_0.asp\">Windows Installer 3.0<\/a>. 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.<\/p>\n<p>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&#8217;t know about N-1 patches because they don&#8217;t yet exist. Under normal circumstances, that wouldn&#8217;t be a problem because the patch transforms would target a specific <code>ProductVersion<\/code>, a service packs &mdash; <a href=\"http:\/\/msdn.microsoft.com\/library\/en-us\/msi\/setup\/minor_upgrades.asp\">minor updates<\/a> &mdash; would change that <code>ProductVersion<\/code> 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.<\/p>\n<p>We need to adjust our conditions for the transitive components, then. Currently, the condition would be something like <code>NOT KB001.Replaced<\/code>, where <code>KB001<\/code> is our unique identifying property defined by the patch. A superseding patch would define <code>KB001.Replaced<\/code>, thus causing the transitive condition for the superseded patch to evaluate to false. Since we know that service packs are to change the <code>ProductVersion<\/code> property, we can change the condition for <a href=\"http:\/\/msdn.microsoft.com\/library\/en-us\/msi\/setup\/small_updates.asp\">small updates<\/a> to <code>NOT KB001.Replaced OR ProductVersion = 1.0.0<\/code> or whatever version is suitable for the actual target of a small update. Minor updates should target the <code>ProductVersion<\/code> that is the final version after the service pack is applied, like <code>NOT KB005.Replaced OR ProductVersion = 1.1.0<\/code>. This also means that a service pack &mdash; which after several released service pack level would potentially define many replacement properties (ex: <code>KB001.Replaced<\/code>) &mdash; would not need to list all patches it replaced because it will change the <code>ProductVersion<\/code> and will cause the previous patches &mdash; even the N-1 patches &mdash; to be effectively superseded.<\/p>\n<p>Thus concludes the series of the <a href=\"http:\/\/blogs.msdn.com\/heaths\/archive\/2005\/08\/05\/448198.aspx\">perils<\/a>, <a href=\"http:\/\/blogs.msdn.com\/heaths\/archive\/2005\/08\/16\/452395.aspx\">necessity<\/a>, and <a href=\"http:\/\/blogs.msdn.com\/heaths\/archive\/2005\/08\/26\/456915.aspx\">workaround<\/a> for defining <code>ARPSYSTEMCOMPONENT=1<\/code> for your product while supporting ARP registry keys for patches.<\/p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>To conclude the series of the problems with ARPSYSTEMCOMPONENT, we will extend the workaround to support setting ARPSYSTEMCOMPONENT=1 to support Microsoft&#8217;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&#8217;ve essentially already developed our own sequencing feature [&hellip;]<\/p>\n","protected":false},"author":389,"featured_media":3843,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[5,20],"class_list":["post-2943","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-arpsystemcomponent","tag-installation"],"acf":[],"blog_post_summary":"<p>To conclude the series of the problems with ARPSYSTEMCOMPONENT, we will extend the workaround to support setting ARPSYSTEMCOMPONENT=1 to support Microsoft&#8217;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&#8217;ve essentially already developed our own sequencing feature [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2943","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/users\/389"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/comments?post=2943"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/posts\/2943\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media\/3843"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/media?parent=2943"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/categories?post=2943"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/setup\/wp-json\/wp\/v2\/tags?post=2943"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}