Setup Launcher Unicode has stopped working, part II

In the past I wrote about a possible InstallScript bug which may cause setup.exe to crash.

However we kept encountering the crash message here and there, although this time when you closed it, the installation process continued normally and finished successfully.

This turned out to be a very random problem which makes it difficult to generalize or reproduce.

Recently, one of my team member found a solution for it: Continue reading

Advertisements

Error -7001 when compiling InstallShield script

This is an issue with InstallShield 2012 and later.

You try to compile your script (Ctrl+F7) and you get an error that ‘in previous builds, the msi was only partially built’. Once you start getting this error it persists.
You can try run a full build again (as the message suggests) but it won’t help you.

The solution? delete the entire Release Folder and then rebuild your project. The next time you try to compile, it should successfully get streamed into the msi.

Cancel or Abort?

A colleague of mine raised an interesting question regarding our installation – what’s the difference between ‘Cancel’ (e.g. in ok/cancel message) and ‘Abort’ (e.g. in an ‘abort/retry/ignore’ message)?
Turns out that there is a logic behind this, one I was using without thinking about:

  • ‘Abort’ means to stop the process since an error occurred (e.g. inadequate disk space, missing prerequisites, problem registering a DLL etc.)
  • ‘Cancel’ means to stop the process since the user wants to (e.g. in the user interview dialogs, during file copying, etc.).

I wonder how many people actually distinguish between these two…

Failed to grab execution mutex. System error 258.

The error in the title can happen during MSI installations, if the msiexec global mutex is not available.

I encountered it while developing a small script that would uninstall all existing JRE versions on the machine and install the latest one (using the msi package).

Apparently the JRE uninstall command spawns the Java Automatic Update (AU) uninstaller, but returns control immediately to the caller. Hence, if I perform a JRE uninstall and immediately start another installation, it would sometime fail with MSI error 258 since Windows Installer is still busy with the AU uninstall.

The best solution I found so far is as mentioned in this Stack Overflow thread. I wrote a small program based on that code, that waits until the mutex is available (or until a certain timeout). So my script now runs the JRE uninstall, then the ‘wait for mutex’ program, and only then it launches the JRE installer, and everyone’s happy 🙂

‘Revocation information not available’ warning when installing JRE 7u51

I have an InstallShield project which, among other things, installs JRE 7u51 by simply calling: jre-7u51-windows-i586.exe /s

When deploying this setup on a vCloud-based virtual machine, we receive the notorious ‘revocation information for the security certificate for this site is not available’.

The reason, as it turned out, is that the jre installer attempts to query a certain web site in order to validate the certificate revocation status of the Java Auto-Updated; and, since the requests comes from a vCloud machine, the web site tries to return the answer to the internal IP, while the server is only accessible through its external IP.

Since we don’t want the auto-update feature anyway (some of our customers are not even connected to the Internet), the solution was to disable auto-updating all together. This is achieved by installing jre with certain MSI parameters.

But here’s another caveat – the jre exe installer does not pass parameters to the MSI when using /v … hence, the solution must be to use the msi directly. Here is how to do it:

1. Run the usual jre installation. While running (or afterwards), open the following folder: %USERPROFILE%\AppData\LocalLow\Sun\Java

2. In that folder, copy the jre1.7.0_51.msi and Data1.cab to another location

3. Change your installation script to deploy jre using the command:

msiexec /i jre1.7.0.msi AUTOUPDATECHECK=0 IEXPLORER=1 JAVAUPDATE=0 JU=0 MOZILLA=1 /qn ALLUSERS=2

4. Test the installation. You should now have no auto-update, and no certificate revocation warning.

Mission accomplished!

Unicode files and InstallShield

I’ve prepared a little test – an InstallScript MSI project that executes the following code:

szFile = TempFolder ^ "web.config"; // A UTF-8 file
listID = ListCreate (STRINGLIST);
ListReadFromFile(listID,szFile);
ListWriteToFile(listID,szFile);
ListDestroy(listID);

Despite the claim that “if the file already exists and the pre-existing file is Unicode, it writes the file as Unicode”, the resulting file is actually ANSI, with two strange characters at the beginning of the file (I assume this is due to the Unicode BOM).

Turns out that InstallShield only supports the UCS-2/UTF-16 LE encoding (the native Windows Unicode implementation). Hence UTF-8 files are not supported.

Bottom line: when processing Unicode files using InstallScript, make sure they are properly encoded!

Use CtrlGetMultCurSel with Extended Selection List Box

The official InstallShield 2013 documentation states the following:

The CtrlGetMultCurSel function retrieves the currently selected lines from a multi-selection list box control, that is, a list box control with the LBS_MULTIPLESEL style. (This function does not support extended selection list box controls, that is, list box controls with the LBS_EXTENDEDSEL style.)

Turns out this is not entirely correct. If you set both list box styles (LBS_MULTIPLESEL and LBS_EXTENDEDSEL), then the list box has extended multi-selection style, but CtrlGetMultCurSel() works well with it.