Wednesday, January 13, 2010

Application Resiliency for Standard Users

Windows Installer has a feature called “Application Resiliency” which, in a nutshell, attempts to make sure that an application’s components are in order before executing the application.

Application Resiliency checks are invoked on a few occasions:

  1. When the user clicks an installer shortcut (which is different from a regular shortcut though the difference isn’t entirely germane to this post).
  2. When the user starts the application via file association (e.g., double clicks on a file extension that’s handled by the app).

These features are configured by registry entries.  The presence of a special key, called a Darwin Description (and described here), causes Windows Installer to do the extra Application Resiliency checks possibly resulting in an automatic repair.

So far so good.  I’m happy to have extra help keeping an application’s components intact.

What happens if the application was installed by an Administrator but the first resiliency check occurs in the context of a user without admin privs?  For example, the administrator installs it then leaves.  The first user to use the application is a user without admin privs.

Some of the resiliency checks require accessing the msi installer package.  This package, at least for one particular installer creating program, is by default left in a location specific to the user that performed the install.

Since non-admin users can’t read this default location, they should fail the resiliency check.

The twist in this particular case is that the user only fails the resiliency check when it is invoked by file extension (e.g., they double click on a file extension that is handled by the app).

A few solutions come to mind.

  1. Use Windows Installer in the “no registry” mode.  This will fix the problem but you give up a lot of functionality provided by Windows Installer.
  2. Manually disable Application Resiliency by deleting the “Darwin Descriptor” registry value after install.  This is bad for several reasons not the least of which is that it relies on an implementation detail that might change.  It’s also hard to do because the registry value appears to be read-only.
  3. Make sure that msi installer package gets installed into a directory that any user can read (e.g., CommonAppData).

1 and 2 are tempting but IMHO these are hackish approaches with too many drawbacks to justify their use.  3 seems to be the way to go but is not entirely without drawbacks: some systems may be so tightly configured that there are effectively no directories that can be read by any user.

No comments :

Post a Comment