When you order pizza delivery, it’s the pizza you want, not the box. In much the same way, an installation program is a means of delivering a deployed product, and not the goal.
The behavior we usually expect from an installation program is for it to run to completion, and then never be seen again. (At least not until uninstallation time, or during manual feature changes or repairs using Add or Remove Programs.) Sometimes, however, an installation program appears to launch itself when an application or document is opened, which can feel like taking a bite of pizza and finding a piece of cardboard in it.
The issue manifests itself by a small installation progress bar appearing when launching an application or opening a file:
The surface cause is that the application was launched by an advertised shortcut (or by opening a file of a type registered by an advertised file association) and the corresponding component’s key path is missing.
Apart from such obvious causes as a user inadvertently deleting a file from an installed product, the deeper cause of the issue can usually be traced back to one of:
- A feature having been installed as advertised/install on first use/install when required
- Files inappropriately shared between components, features, or products, which can lead to the resource being uninstalled while a product is still using it
- A product with per-user data having been installed on a multi-user system by one user and then launched by another user
The general Windows® installer feature is called self-repair or resiliency, and it’s part of Windows Installer’s core functionality. There’s no real way to disable this functionality, either globally or for a particular product, without disabling the Windows Installer service. One way to get the same effect is by creating standard, non-advertised shortcuts in the Shortcuts view and by disabling feature advertisement by setting features’ Advertised setting to “Disallow Advertise”, along with writing file-type and COM data directly in the registry. (A more drastic remedy is avoiding the use of key files, but doing this disables a good deal of Windows Installer functionality that depends on key files.)
To investigate the resource whose absence triggers self-repair, look in the Application section of the system’s event log. Self-repair events are displayed with source “MsiInstaller”.
Viewing that the event properties shows the product code, component code, and specific missing resource.
If this occurs on your build system, you can use InstallShield’s MSI Sleuth utility, introduced with InstallShield 2009 Professional and Premier editions, where you enter a component code and the tool displays the product and publisher name. In MSI Sleuth, select File > Open by Component Code, and paste or enter the component code that appeared in the event log.
When you press Enter, InstallShield MSI Sleuth displays the product or products currently using that component.
Keep in mind that InstallShield MSI Sleuth can display information only about components that were installed using a Windows Installer package, and not resources installed by (for example) a pure InstallScript installer or a batch file. To investigate data installed by an InstallScript installation program, the InstallShield Log File Viewer supports searches, such as for a file name.
Installation programs that run smoothly may not be as good as a slice of cheese pizza (without the cardboard), but at least you have some tips that can help you to avoid this type of behavior in the future.