Step 5: Redesign Your Installer (UAC)
Step Five: Redesign Your Application's Installer
The following best practices are for well-behaved application installations in a Windows Vista® or UAC environment. This list is not comprehensive. For a more detailed explanation of the Logo Requirements for Windows Vista, including the UAC requirements, please see the Windows Vista Logo documentation and the in-depth version of the latest draft of the Windows Vista Logo guidelines document (https://go.microsoft.com/fwlink/?LinkId=71497).
Use these requirements while redesigning your application.
Use the Windows Installer 4.0 for your setup package. Many of the following requirements are already integrated into the Windows Installer engine. Using Windows Installer for your setup package will assist you with following Windows Vista installation requirements.
Use versioned files and do not downgrade files during installation. File versioning ensures that the final installation state is correct when setup is complete. Without file versions, some special handing will be needed to ensure that your installation works properly for many different installation scenarios. Also, when installing versioned files, do not downgrade versions, especially shared files. Downgrading versions may be good for your application, but it frequently causes issues with other applications. By declaring the correct versions of your files in your Windows Installer package, Windows Installer natively supports this feature.
Install applications and store per-user data in different locations. Applications should be installed in a folder under the Programs Files directory. To configure this, you can use the ProgramFilesFolder property in the Directory table of your Windows Installer package. Per-user configuration data should be stored in files either under the \Users\Username\AppData directory or in registry keys under the HKEY_CURRENT_USER root. User data, templates, and application-created files all have proper locations in the \Users\Username subdirectory. Although this was not enforced in the past, since many users would run programs with a full administrator access token, applications that do not place information in the correct location are likely to fail. This is especially true when virtualization is disabled.
Use a consistent folder location when installing shared components. Shared components should be installed to the Common Files directory by using the CommonFilesFolder property in the Directory table of your Windows Installer package. Managing shared components can be problematic and should be avoided, if possible. A developer who does not install shared components consistently can end up with Component Object Model (COM) registration information pointing to older components. The Windows Installer Merge Modules (MSM) feature is specifically designed to enable shared components to consistently install in the context of all packages that install the shared component. Other problems arise when modifications of shared components cause existing applications to fail. One way to address this issue is for applications to be built using Microsoft .NET– or Win32–versioned assemblies.
Perform setup rollback if an installation fails. Partially installed software can fail in strange and unexpected ways providing for a poor user experience. Windows Installer supports this rollback feature.
Do not install application shortcuts all over the user’s profile. While it may be tempting to add your application icon to every known exposure point in Windows, it often results in users feeling that they have lost control of their computer. Users are then forced to manually remove these shortcuts to return the computer to a desired look and feel. If the developer wants to add icons to the desktop, ask the user for permission during the installation. Windows Vista addresses discoverability of applications post install and includes the most recently used application list to avoid excessive Start menu traversing.
Avoid automatically launching background applications at user logon. Although it is possible to add programs to the startup group or Run key during installation, it adds overhead to the system. Over time, the performance of the user’s computer can significantly degrade. If your application can benefit from a background task, allow it to be user-configurable. Also, adding a startup task with the HLKM run key may prevent a standard user account from modifying the behavior in the future. If the user wants an application to launch at logon, store the information in the run key of HKEY_CURRENT_USER.
Follow clean removal logic. A user might remove an application not only to free up disk space, but also to return the computer to its state prior to the application being installed. The application’s uninstall process should correctly and fully remove the application. Windows Installer defaults to the following removal rules:
All non-shared application files and folders.
Shared application files whose reference count (refcount) reaches zero.
Registry entries, except for keys that might be shared by other programs.
All shortcuts from the Start menu that the application created at the time of installation.
User preferences may be considered user data and left behind, but an option to do a completely clean removal should be included.
The uninstaller itself (if not using Windows Installer).