Changing default checkbox state of a 3rd party InstallShield installer

Question

I am writing an installer/bundle of several software packages that our customers frequently need to install. Basically it just includes several executable installers in it. For each component the user chooses, it extracts the installer to a temporary folder and runs it.

One of these installers is for AVR Studio 5.1, and it is made by a third party (Atmel). It can be downloaded here: http://www.atmel.com/Images/as5installer-stable-5.1.208-full.exe (616 MB).

Unfortunately, Atmel added a checkbox at the end of the installer that gives the user the option to launch AVR Studio 5.1, and it is checked by default:

If the user just clicks "Finish", as most users probably will, then AVR Studio 5 will take over the screen and my installer will be left in the background. The user will probably forget about my installer and fail to finish installing the other components of the bundle.

Can anyone think of a good solution to this? I've thought of some:

1) The 3rd-party installer appears to be written with InstallShield. Is there some standard way I can pass a command line option to an InstallShield installer to disable the checkbox or change its default state to unchecked?

2) My current solution is to sleep for 10 seconds after 3rd-party installer finishes and then bring my installer window to the front using NSIS's BringToFront command. It works for me on Windows 7 Pro but I've heard it doesn't always work and might instead just highlight the window.

3) Doing a silent install doesn't seem to work. When I try it from the command line, the 3rd party installer just runs for a bit and then quits. If you get that to work, let me know.

4) Unfortunately, I can NOT just run the 3rd party installer last, because one of my other installers needs to run after it and copy some files into its installation directory.

My installer is written in NSIS, if that makes a difference. Thanks for any advice!

---

Update 1, 2012-02-27, 6:30pm:

Thanks for the tips from Michael Urman (the technical lead at InstallShield!) and Christopher Painter. Christopher says the installer in question is an InstallScript InstallShield installer, not an MSI-based InstallShield installer. I found this article about InstallScript vs. InstallScript MSI which helped me understand the difference.

We now have two ways of extracting the files from the installer: using UniExtract or running as5installer-stable-5.1.208-full.exe /extract_all:c:\extract. These two ways seem to extract the same set of files, which you can see here:

I am unable to extract the *.cab files by double clicking on them or using UniExtract. I am unable to extract setup.exe using UniExtract. I can run setup.exe and it seems to behave the same as as5installer-stable-5.1.208-full.exe. There is a setup.iss file which looks kind of similar to the file I created when I tried a silent install. You can see the contents of setup.iss if you want.

I wonder: is it normal to have a setup.exe inside an installer or is Atmel doing something odd? Is running this setup.exe equivalent to running as5installer-stable-5.1.208-full.exe? Also, is it normal to have a setup.iss inside the installer and what purpose would it serve?

You can also look at files in the installer using 7-zip but it's a different set of files that don't seem to be fully extracted.

Christopher's suggestion was that one of the bOpt1, bOpt2, or bOpt3 options at the end of the .iss file corresponds to the checkbox I am trying to disable. Combining that with Michael's suggestion, I tried installing AVR Studio 5.1 with the following commands:

as5installer-stable-5.1.208-full.exe /v"bOpt1=0 bOpt2=0 bOpt3=0"
as5installer-stable-5.1.208-full.exe /v"bOpt1= bOpt2= bOpt3="
setup.exe /v"bOpt1= bOpt2= bOpt3="

Unfortunately, I didn't observe any difference in behavior. The checkbox was still checked and it still launched AVR Studio 5.1 when I clicked Finish. Maybe I'm specifying multiple property overrides on the command line in the wrong way? I have a few more ideas of things to try but I'm interested to know if anyone else has any ideas too. Is there any way to use a .iss file without doing a silent install or is that its only purpose?

Answer 1

Ok, I finally found some free time to download that EXE and here's what I found.

It's an InstallScript installer not MSI. So run the following command ( from elevated command prompt) :

as5installer-stable-5.1.208-full /extract_all:c:\extract

Now grab the files found in C:\extract\disk1

For InstallScript projects you have the concept of recording and playing back the UI.

• /r - record
• /s - silent
• /f1 - path to silent response file ( .iss )
• /f2 - path to log file

The package already has a setup.iss file. Take a look at the end of it:

[{D574D18C-9D52-4B4B-9647-AE6B89FD3F70}-SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
bOpt3=0

One of those boolean options is the value you need to change. I'll leave it to you to figure out the rest. You may have to record a new ISS file and it's always possible that someone wrote some craptastic installscript that always sets that checkbox to true regardless of what you do. In those cases you have to break out the repackaging tools and convert it to MSI format.

Answer 2

Checkboxes are associated with properties, and typically these will be public properties. If so, you can likely override that property on the command line, either msiexec /i the.msi PROPERTY=override-value, or setup.exe /v"PROPERTY=override-value". However it's possible that it's a private property, or is otherwise overridden inside the installer. In that case you may have to create a transform instead. (You apply the transform by listing it in the TRANSFORMS property on the command line.)

In light of the update that the installation is an InstallScript based one, the above command-line recommendations do not apply. A custom script could make them (or something similar) work, but it is uncommon. More common is the support for silent scripts as Christopher alluded to in his answer with the /r and /s parameters. However it sounds like the installation in question might be doing something interesting with a silent script already, so integrating this approach may not work. I would suggest repackaging (as Chris has) or contacting the vendor.