The Dangers of ARPSYSTEMCOMPONENT

The Dangers of ARPSYSTEMCOMPONENT

  • Comments 10

Back in March I wrote about the dangers of using the RunOnce and Run registry keys. This is another post to help you avoid some other pitfalls.

The ARPSYSTEMCOMPONENT property in Windows Installer does not actually do anything directly to your installation — Windows Installer doesn't even check for it. What does happen, however, is that the Add/Remove Programs (ARP) control panel applet normally queries Windows Installer for application and patch information. When ARPSYSTEMCOMPONENT is defined for a package, all the data is read from the registry key under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall.

When ARPSYSTEMCOMPONENT is defined the installation package and patches are responsible for writing their own ARP registry keys and values. That's easy enough to do using the Registry table or a custom action. But what happens when a patch — perhaps a service pack, or minor upgrade — is installed?

If ARPSYSTEMCOMPONENT is defined and set to 1, then when the patch is obsoleted, superseded, or uninstalled (starting with MSI 3.0) the patch is removed from the view created by starting with the product and layering the applicable transforms provided by the patches. If the patch is removed from the view, then all information about those ARP keys are lost. The ARP keys have now been orphaned. If ARPSYSTEMCOMPONENT was not defined then Windows Installer wouldn't have reported the obsoleted, superseded, or uninstalled patch to ARP and the ARP entry wouldn't have been displayed.

Be careful when deciding to write your own ARP entries by defining ARPSYSTEMCOMPONENT. You can still set properties like ARPPRODUCTICON to display in ARP, but having ARP read everything including your UninstallString, DisplayName, and other registry values means that you're responsible for adding and removing those values, the latter of which is difficult when your patch that defined then, for example, is removed from the view.

Leave a Comment
  • Please add 7 and 3 and type the answer here:
  • Post
  • Reasons for setting ARPSYSTEMCOMPONENT to 1 despite the dangers.
  • I found a couple of recent posts by Heath Stewart that describe the ARPSYSTEMCOMPONENT property that...
  • How to work around the issues with ARP when defining ARPSYSTEMCOMPONENT=1.
  • How to work around the issues with ARP when defining ARPSYSTEMCOMPONENT=1.
  • How to support N and N-1 with the workaround for defining ARPSYSTEMCOMPONENT=1.
  • What patches do when being installed or uninstalled.
  • V. Good
  • great article
  • Hello Heath,

    "When ARPSYSTEMCOMPONENT is defined the installation package and patches are responsible for writing their own ARP registry keys and values. That's easy enough to do using the Registry table or a custom action."

    The above statement of yours indicates that when the ARP entries under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall are not written by the windows installer service , when ARPSYSTEMCOMPONENT=1 is defined within a msi package.

    However, i have tested  this by passing  ARPSYSTEMCOMPONENT=1 to a .msi package on the command line. I have found that the ARP entries are created as expected just like in a normal case.

    Could you kindly elaborate further?

    Regards,

    Kiran Hegde

  • @Kiran, I didn't say they weren't written. I said they were ignored, which indeed they are. This is done by the REG_DWORD, SystemComponent, set to 1. ARP ignores any entries then, as well as if they lack the UninstallString. This is also why it's important you don't write your own ARP keys using the ProductCode, which is what Windows Installer does (they would also be ignored). Using the ProductName or some other arbitrary value is typical.

Page 1 of 1 (10 items)