Tips for best practices with Installshield

Installshield allows you to create powerful MSI projects in comparison with the pale and unfinished tool that is shipped with Visual Studio 2005/2008/2010. It seems that although the structure of these files was defined by Microsoft, it was not in their intention to provide an SDK of some kind that will suffice most of the developers needs.

  • Custom actions. When creating a new custom action, it is important to instruct Installshield as to when exactly this action should be fired. Use launch conditions to get this work as intended. If the action is used in an installation scenario, the launch condition will be "Installed" otherwise "NOT Installed".
    To discern between 64 bits and 32 bits system use "VersionNT64" and "NOT VersionNT64".
    Choose after which predefined action your custom action should come right after. Select from the Install exec sequence - usually "After Install files" or "After remove files".
  • XML File changes.
    Suppose we want to modify/create a web.config file.
    It may happen that the appSettings element contains more than one "add" child.
    The right syntax of doing this is:
    add[@key=keyName and @value=valName], replace the keyName and valName with the real values. It can also consist of the predefined Installshield path variables such as [WindowsFolder]
  • Path Variables.
    Variables such as [WindowsFolder] can be concatenated with strings with the ^ operator. This way we can write: [WindowsFolder]"Folder1" ^ "Folder2". Be aware that after the "[ ]" brackets there is no need for neither "^" nor "\"
  • Features that depend on a launch condition. It won't work unless you fully understand what happens behind the scenes.
    The scenario may be for instance when we want to have two features - one for 64bit OS and the other for 32bit. The user won't be prompted to select which features he would like to enable/disable.
    If we set launch conditions such as "VersionNT64" and "NOT VersionNT64" it won't work. Why? because if you look in the dialogs - SetupType dialog, and check the behaviour property, you'll see that the "Next" button fires an event that forces the installation of all the features no matter what.
    Change the "AddLocal" event to install the features you like based on your custom condition.
  • Path Variables in InstallScript driven project.
    If you're building an InstallScript project (Not MSI) then the predefined path variables are named differently.
    WINSYSDIR=SystemFolder
    PROGRAMFILES=ProgramFilesFolder
    COMMONFILES=CommonFilesFolder
    WINDIR=WindowsFolder
    TARGETDIR=INSTALLDIR
  • Installing .NET assemblies to GAC. That is a bit frustrating and out of reach when using the InstallScript based project (Not MSI). We have to copy the non redistributable gacutil.exe and manualy use the LaunchApp function for a command line installation. Another option is to create an MSI project merely for this purpose and install it in a commanline.
  • Checking if registry key exists. Try to use this command:
     if RegDBKeyExist ( svRegistry ) then

Post a Comment

Previous Post Next Post