Passing parameter to a WiX msi installer

WiX Windows InstallerIt’s pretty much impossible to pass a parameter to a msi installer downloaded. There’s the possibility of deploying a web-based click-once application from Visual Studio, but passing arguments to the installer requires the end user to use the IE browser – and who the would want to do that?

The WiX framework is a great and powerful one for creating installers. If you need to pass a parameter to a WiX based msi installer you can use two methods as far as I know. Both are based on the filename the user downloads so there’s no need for per-user compilation or anything like that.

Method 1: uniqueid.msi

You can package you application in a .msi-file and rename the file for each user that downloads it. Lets say user A gets the file A875.msi and user B gets the file H567.msi. Both are the exact same, but the filenames are different.

In the .wxs-file (WiX input file for candle) you can get the full path of the .msi installer by using the parameter [OriginalDatabase]. This parameter is stored by Windows to keep track of the original installer path of the application.

Note that this parameter will return the full path with extension (i.e. “C:\Users\username\Downloads\A875.msi”) and not just the filename. You will need to extract the ID somehow if you want to use it.

In my case I wanted a script to be run after the installer was completed, actually after the machine was rebooted, so what I did was this:

<RegistryValue Root="HKCU" Key="Software\Microsoft\Windows\CurrentVersion\RunOnce" Name="Application Name" Type="string" Value='"[INSTALLDIR]CustomScript.exe" "[OriginalDatabase]"' />

The CustomScript.exe application is packaged in the .msi-file as well. I’ll get back to this in a later post. The CustomScript.exe will have to extract the unique-id from the full path and do something useful with it. In my case the script goes online and fetches user settings for the application so the user won’t have to provide any details manually. Of course the user is authenticated online before the download.

This will be the user experience:

  1. The user logs on online with a browser
  2. The user requests a download of the client application
  3. The .msi file is served with a user specific filename (i.e. “A875.msi”)
  4. The application is installed and when completed, requests a reboot
  5. When the client OS restarts and the user logs on, the client gains access to the service

Method 2: bootstrapper

By embedding the .msi-file in an .exe-file you may run the .msi file from the .exe app with parameters. If you choose this path you can give the .exe file the unique name and initiate msiexec like this:

msiexec.exe /i installation.msi CUSTOMID=A875

In the .wxs-file (WiX input file for candle) you may refer to this parameter like so:

<Property Id='CUSTOMID'></Property>
...
<RegistryValue Root="HKCU" Key="Software\Microsoft\Windows\CurrentVersion\RunOnce" Name="Application Name" Type="string" Value='"[INSTALLDIR]CustomScript.exe" "[CUSTOMID]"' />

NB! You do need to use UPPER CASE characters to let WiX know your parameters are in the public scope!

Why embed the .msi-file in a bootstrapper when you just as easy (actually easier) just use a .msi-file?
Well, if you need to be architecture independent and support both 32 and 64-bit platforms you will have to embed .msi-files for each platform in an .exe file. .msi by design does not support both architectures at the same time, but .exe files can be compiled to do so. I’ll come back to this subject in a later post.

This will be the user experience:

  1. The user logs on online with a browser
  2. The user requests a download of the client application
  3. The .exe file is served with a user specific filename (i.e. “A875.exe”)
  4. The .exe file is run and the user sees the command prompt briefly before the .msi installer initiates
  5. The application is installed and when completed, requests a reboot
  6. When the client OS restarts and the user logs on, the client gains access to the service

I’m sorry if I’m a bit off on the WiX-terminology.. Please comment if so!

  1. No comments yet.

  1. November 19th, 2011