The Dangers of ARPSYSTEMCOMPONENT
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_MACHINESoftwareMicrosoftWindowsCurrentVersionUninstall.
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.
Light
Dark
0 comments