Ten Tips for Well Behaved Application Installations

- Micheal Dunn – Windows Deployment
 

1.                Use Windows Installer for your setup script

Many of the below tips are accounted for in the Windows Installer (MSI) engine, and you risk not following good setup design with other engines or building your own from scratch. Windows Installer is very mature now and is up to version 3.0.

2.                Use versioned files and don’t downgrade files on install

File versioning ensures the final install state is correct when setup is complete. Without file versions some special handing will be needed to ensure your install works properly over many different install scenarios. Also when installing versioned files don’t downgrade versions, especially shared files!! It may be good for your application to downgrade, but almost always causes issues with other applications.

3.                Use correct folder for correct file type or risk post install app failures

This tip might be more about application runtime issues than install. Applications should be installed into programs files today. This folder though is not appropriate for user data. User data, templates, and application created all have proper homes in the Documents and Settings branches in Windows. Older versions of Windows did not enforce this well with many users running as admin today. In the future if you don’t follow this tip your application likely will just fail.

4.                When installing shared components use a consistent folder location or risk making a big mess!!

Handling shared files in an install is hard, and if you can avoid it…do!! If you don’t install shared components consistently you could end up with bad COM registration info pointing to older components. This is also the typical support problem where multiple DLLs at different version reside in different folders. Depending on app load order and how DLL is loaded the system will return different results. Typically this leads to random issues or people needing to uninstall applications and reinstall in a certain order. To solve this issue long term programs should start using .NET or Win32 versioned assemblies.

5.                Be clear to the user when installing shared components or updating OS pieces

When users install an application they don’t typically expect other applications to break. You run the risk of breaking application whenever you installed shared components on the system. The user should be informed or shared component installs that could affect other applications. You should note in read me or support info how to correctly remove the shared components you install if  is left behind on your application uninstall do to reference count handling. If your application can follow more of a per user isolated application model you will not have to deal with the hard issues of shared component updates. Visiting a web site for example doesn’t break a machine typically, it’s because the site doesn’t touch shared machine state.

6.                Don’t let a partial install succeed, have setup rollback

When a setup is complete it should be in a state as tested by your release team. Allowing a partial setup to succeed just confuses the user as to what state their machine is really in. Windows Installer already has such support, and should leverage this model in custom actions you add to your installer.

7.                Don’t spam the users system with application shortcuts

Well as tempting as it may be to add your application icon to every known exposure point in Windows it’s one of the ways a user feels they have lost control of their machine. Post install a user has to manually remove icons to get the machine back to how they like it to look. If you do need to add icons to the desktop for example, ask the user during the install if it’s OK to do so. Newer versions of Windows address discoverability of applications post install and most recently used app list to avoid large start menu traversing.

8.                Don’t add background applications to the startup group or run branch during install

While it’s possible to add components to startup group or run branch during install, just don’t do it. One of the reasons people uninstall applications is their machine has slowed down due to all the added background tasks apps have added over time. Instead let this happen on application first run or in the application feature UI if the user really wants the background task added to their machine working set. The mere fact of installing the app shouldn’t hurt machine performance, and users will be less likely to uninstall your app in the first place. Any machine can only handle so many background processes and there isn’t a good mechanism at install time to judge how much headroom a machine has left for your task. Definitely at uninstall do remove all your background tasks from the system to avoid bad error prompts and return system performance.

9.                Follow clean uninstall logic

A user uninstalls an application to free up disk space, but also does so to try to return their machine to the state before the application was installed. The application’s uninstaller should correctly and fully remove the application. Windows Installer defaults to these 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)

10.           Uninstall removal must be clean enough to allow the application to be reinstalled later!!!

This is a very important rule. If a user can’t reinstall your product after they uninstall it they will either need to reinstall Windows or return your product. Neither solution is enjoyable to you or the user. Many uninstall and reinstall tests are conducted under clean machine or single app scenarios. You should broaden your test scenarios to cover more mixes of versions especially when dealing with shared components in the installs too.