Installation considerations

From ISXKB

Revision as of 01:26, 4 July 2007 by Markus (Talk | contribs)
Jump to: navigation, search
This article is currently work in progress. You can help to improve the ISXKB by extending this article.


Contents

Introduction

Inno Setup is an easy-to-use and quick, although very powerful, solution for software developers who want to deploy their applications by providing a setup program.

Inno Setup Script Wizard
Inno Setup Script Wizard

In theory, creating a setup program with Inno Setup should not take more than a few minutes if the Inno Setup Script Wizard is used. It is invoked by selecting 'File', 'New' from Inno Setup's main menu. If the script wizard doesn't show up then it is switched off under 'Run', 'Options'.

The wizard creates quite good scripts and should be sufficient for standard setups.

Software installers are usually powerful tools in general. In most cases setup programs will be run by the computer administrator and could do a lot of harm to the computer they are installed on. It is therefore important to develop them cosiderably and with great care.

Before and during the creation of an installer for your application it is advised to follow some basic rules to avoid issues and annoyances. Following those rules not only improves the relationship between software developers and users; they can even avoid serious damages to the target machines, which in turn could cause legal battles between the parties.

Owner of the target computer

The probably most important thought that should come up when creating an application or a setup is the one about the respect for the user and the user's computer.

Whatever your installer or your application does, always consider that it does this not on your computer system, but on somebody else's. You, your installer, or your application, are not the owner of that computer system.

Do not make any decisions for your users which they may not like or want. If you really have to or want to, give them a choice to intervene before you finally do it. Your application may be good, but it is certainly not the best application in the world, and there might be users out there who don't want or need it. If they really installed it they might not want to see it in the Quick Launch bar or on their desktop. Let the users decide if they want it or not.

Installation

Treat the user's file system and files with care. Don't delete anything that doesn't belong to you. Don't remove registry keys or values that were not created by your installer or your application.

The following examples are some of the worst things you can do. The semicolons are there for the case where someone who's too lazy to read this text just copies and pastes.

Files and Folders

Grandmother's pictures where they shouldn't be
Grandmother's pictures where they shouldn't be

Never delete an application folder just before installing a new version. You can't possibly guess what the user has put into that folder. If he accidentally moved Grandmother's picture gallery into it just the day before he'll certainly love you for your worries about the few old scrap DLLs your previous installation has left.

[InstallDelete]
;Type: files; Name: "{app}\*.*" Flags: filesandordirs

Don't even think about deleting anything that has an asterisk in the file name.

[InstallDelete]
;Type: files; Name: "{app}\OldData\*.*" Flags: filesandordirs

You can't have any 'Old Data' on the user's system that needs to be removed, not even conditionally. The data is not yours at all, and you have not the slightest idea what's in a folder anyway. Think about the picture gallery whenever you're just about to implement the deletion of any data. For folders, always use the flag 'dirifempty' and without asterisks:

[InstallDelete]
Type: files; Name: "{app}\OldData" Flags: dirifempty
Type: files; Name: "{app}" Flags: dirifempty

Registry Keys and Values

Don't delete any registry keys or values during the installation.

There can't be any serious reason why you would delete any registry keys or values in an installer. If you're not happy with some data a previous installation has left then name every single one in a [Registry] section with the appropriate parameters or just leave it.

Uninstallation

The same rules for the installation process almost identically apply for the application's removal again.

Treat the user's file system and files with care. Don't delete anything that doesn't belong to you. Don't remove registry keys or values that were not created by your installer or your application.

Files and Folders

Never remove any files or directories with an asterisk in the name. Have a look at the example with Grandmother's pictures to understand the reason why you shouldn't do that.

Registry Keys and Values

Don't touch anything at HKEY_CURRENT_USER (HKCU) with the installer or the uninstaller.

Some users only uninstall an application just because they want to reinstall it shortly afterwards. If you use the following example out of Inno Setup's help file without care you will delete their personal settings, if there are any.

[Registry]
Root: HKCU; Subkey: "Software\My Company\My Program"; Flags: uninsdeletekey

It goes without saying that the above example is not annoying if your application does not store any personal settings. On the other hand, if your application does not store any personal settings in the registry, why would you create this key in the first place?

At least give the user a choice to decide whether he wants your application uninstalled forever or if he wants to just remove it for now but keep his settings. Always default to 'Keep the settings'.

[Tasks]
Name: keepsettings; Description: "Keep Personal Settings"; GroupDescription: "Settings";

[Registry]
Root: HKCU; Subkey: "Software\My Company\My Program"; Flags: uninsdeletekey; Tasks: NOT keepsettings

Or:

[Tasks]
Name: removesettings; Description: "Remove Personal Settings"; GroupDescription: "Settings"; Flags: unchecked

[Registry]
Root: HKCU; Subkey: "Software\My Company\My Program"; Flags: uninsdeletekey; Tasks: removesettings

Bare in mind, as mentioned before, neither an installer nor an uninstaller should touch HKEY_CURRENT_USER at all. If your application relies on some keys or values beeing created there during the setup process it will fail anyway if a different user logs on. Keys and values under HKEY_CURRENT_USER should only be created or removed by the application.

The uninstaller can't remove these keys and values for other users anyway. This is by Windows design. You can't change this. So why would you want to delete them for one user but not for others? It's best practice to just leave them as they are. As said, this is Windows design, and your uninstaller is not the first and the only one that will leave them behind, which is the entirely correct way. Microsoft don't give you a reliable way of deleting this data.

Do not make any mistakes like this one:

[Registry]
;Root: HKLM; Subkey: "Software"; Flags: uninsdeletekey;

The semicolon is there for a reason! In the above example, during the removal of the software the whole 'Software' key of the system is removed! Needless to say that this system won't work anymore. The only hope that's left is that the user has an operating system that supports restore points, and that a restore point had been created prior to the removal.

Start Menu Folders and Shortcuts

Start menu links are files and folders as well. Do not delete them with asterisks in the names. You don't know what other shortcuts the user has put in these folders. If your application is a file viewer the user could have tried to tidy up his start menu and moved some other similiar shortcuts to other file managing utilities into the folder of your program.

External Links

The Old New Thing An article about treating the Quick Launch bar and the Favorites menu

Personal tools
Ads: