Source Resiliency, A.K.A. Package Self-Repair

Software packages should not automatically repair data (local- or server-based data) on launch. Such an automatic repair could overwrite data changes made by the user. Therefore, components in the MSI that include data files (e.g. Access MDBs) will not contain a key path (thus disabling self-repair), even if this breaks the Windows logo.

The Self-repair (Source Resiliency) process will be reserved to repairing locally installed application executables, registry keys, shortcuts and system files. The package will never be able to repair to a server path (since the application is Run from Source and it is read-only), and under no circumstance should the package repair Data (User or Shared) even if the data resides locally.

In order to support roaming users or more specifically, multiple users using the same application on the same workstation, user data needs to be installed for each user using the application on the workstation.

In order to do this, a HKCU key should exist in the separate feature in the wsi, which will cause an install (or intentional one-time self-repair) of this feature for each user. This feature components should have the property "Leave installed on un-Install" and each component should not have a key path. This will be very useful in making the package to avoid self repairing.

There can also be a case when the application which contains HKCU keys undergoes a machine level deployment. In this case, when every user launches the shortcut, the application package will self-heal. This can be avoided by using active Setup which was discussed in previous articles of mine.

Some other reasons which causes the package to self-repair

1. Having a temporary registry key as a component keypath.
2. Having a temporary file as a component keypath.