Installation considerations


Jump to: navigation, search



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 'Tools', '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.


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.

;Type: filesandordirs; Name: "{app}\*.*"

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

;Type: filesandordirs; Name: "{app}\OldData\*.*"

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.

Name every file separately in the [InstallDelete] section:

Type: files; Name: "{app}\oldfile1.txt"
Type: files; Name: "{app}\oldfile2.dat"

This avoids inconvenient surprises on the user's end.

Sometimes you don't know the names of the files you'd like to delete. That could be the case for log files or any other pseudo-randomly created file. In this case the wildcard character '?' should be used as narrow as possible. The '?' wildcard only evaluates to a single character. For instance, to delete log files in the form 'mylogfile yyyy-mm-dd.dat' use an [InstallDelete] or [UninstallDelete] entry like this:

Type: files; Name: "{app}\mylogfile ????-??-??.dat"

Let's assume the application has somehow created files 'junkfile1.dat', 'junkfile2.dat', 'junkfile15.dat', 'junkfile27.dat', etc. In this case use

Type: files; Name: "{app}\junkfile?.dat"
Type: files; Name: "{app}\junkfile1?.dat"
Type: files; Name: "{app}\junkfile2?.dat"

to refine the matches as restrictive as possible.

For folders, always use the Type 'dirifempty' and without asterisks:

Type: dirifempty; Name: "{app}\OldData"
Type: dirifempty; Name: "{app}"

Registry keys and values

Don't touch anything under 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 the personal settings of the user who uninstalls your software, if there are any.

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

Bear 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 anything under HKEY_CURRENT_USER for other users. 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 entirely the correct way. Microsoft don't give you a reliable way of deleting this data.

Start menu folders and shortcuts

Start menu links are files and folders as well. Inno Setup can therefore easily remove them from the target computer. The shortcuts' file extension is '.lnk'. The default Windows setting is to not display file name extensions for known file types. On Windows XP this option can be found under 'Tools' in Windows Explorer, then 'Folder options' on the page 'View'.

Here is how it works: The last version of your installer had a typo where 'Shortcut' was accidentally spelled 'Shortcutt'. Your new version has corrected this but everyone who's installed the previous version now has a mis-spelled shortcut in their start menu. The following [InstallDelete] entry can correct this.

Name: {group}\Shortcutt to my program.lnk; Type: files

As said above, do not delete any files or folders with asterisks in the names. Start menu links are nothing but files and folders. So, do not use this:

;Name: {group}\Shortcut*.*; Type: files

You don't know what other shortcuts or files 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.


At the end of a successful installation it is nice for the user to have a 'Launch My Program' checkbox to start playing immediately with the program.

The picture has been created with the script wizard. The required bits from the script are here:

#define MyAppName "My Program"
#define MyAppExeName "MyProg.exe"

Filename: "{app}\{#MyAppExeName}"; Description: "{cm:LaunchProgram,{#MyAppName}}"; Flags: nowait postinstall skipifsilent

Do not omit the flag skipifsilent, under no circumstances. If the installer is executed in silent mode (/SILENT or /VERYSILENT parameters) the application will not be started at the end of the installation when skipifsilent is there. Users or administrators have a reason for wanting a silent installation, and in this case they will start your application at a later time, if they like so.

It looks very "nice" when an administrator finds your program good enough to be installed on a whole bunch of computers under his responsibility in a bundle that installs many applications in one go, and then finally one application leaves the queue and wants to show off with a window that does not belong to the installation process.


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.

Do not make any mistakes like this one:

;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.

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 under HKEY_CURRENT_USER (HKCU) with the installer or the uninstaller. HKEY_CURRENT_USER should be for the application only.

Some users only uninstall an application just because they want to reinstall it shortly afterwards.

Here's one of the worst examples again. Do not make any mistakes like this one:

;Root: HKLM; Subkey: "Software"; Flags: uninsdeletekey;

According to the Inno Setup newsgroups this happened to several people already. They forgot to add their application's name and deleted the whole 'Software' key from the target computer.

Start menu folders and shortcuts

Upon uninstallation Inno Setup will automatically remove all start menu entries and shortcuts the installer has created. If a folder, ie. a start menu group, contains other shortcuts Inno Setup will not delete this folder. This is the way it is supposed to be.

Do not try to change this behaviour, do not force the deletion with an '[UninstallDelete]' section.

Don't touch what you haven't created. As for the shortcuts and menu entries, Inno Setup does the work. No need to interfere.

User specific data

Unless your application is meant to be installed by any user without administrative rights and only run by that particular user you should not touch anything user specific from the installer.

Folders like {userappdata}, {userdesktop}, {userdocs}, etc. (basically all Inno Setup constants that start with 'user...'), are not available for other users on that computer. If you need to create data in these folders you should do this with your application and not with the installer.

The same applies to the registry. Don't touch HKEY_CURRENT_USER with your setup. If you have to and your application relies on it your program will fail to run as soon as a different user logs on.

Since these "installers" are actually applications (they only use Inno Setup's scripting language at run-time) these rules do of course not apply to them.


This article is intended for software that 'goes on the market', from developers to customers, from the vendor to the end user or administrator.

It does not cover any inhouse solutions. Inhouse and special-purpose solutions are exempt and may require purpose-driven treats.

See also

External links

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