WiX tricks and tips

Answer 1

Installing to C:\ProductName

Some applications need to be installed to C:\ProductName or something similar, but 99.9% (if not 100%) of the examples in the net install to C:\Program Files\CompanyName\ProductName.

The following code can be used to set the TARGETDIR property to the root of the C: drive (taken from the WiX-users list):

<CustomAction Id="AssignTargetDir" Property="TARGETDIR" Value="C:\" Execute="firstSequence" />
<InstallUISequence>
    <Custom Action="AssignTargetDir" Before="CostInitialize">TARGETDIR=""</Custom>
</InstallUISequence>
<InstallExecuteSequence>
    <Custom Action="AssignTargetDir" Before="CostInitialize">TARGETDIR=""</Custom>
</InstallExecuteSequence>

NOTE: By default, TARGETDIR does not point to C:\! It rather points to ROOTDRIVE which in turn points to the root of the drive with the most free space (see here) - and this is not necessarily the C: drive. There might be another hard drive, partition, or USB drive!

Then, somewhere below your <Product ...> tag, you need the following directory tags as usual:

<Directory Id="TARGETDIR" Name="SourceDir">
    <Directory Id="APPLICATIONFOLDER" Name="$(var.ProductName)">
        <!-- your content goes here... -->
    </Directory>
</Directory>

Answer 2

Environmental Variables

When compiling your Wxs documents to wixobj code, you can make use of environmental variables to determine various information. For example, lets say you want to change which files get included in a project. Lets say you have an environmental variable called RELEASE_MODE, that you set right before you build your MSI (either with a script or manually, it doesn't matter) In your wix source, you can do something like:

<define FILESOURCE = c:\source\output\bin\$(env.RELEASE_MODE) >

and then later in your code, use it in place to on the fly change your wxs document, eg:

<Icon Id="myicon.ico" SourceFile="$(var.FILESOURCE)" />

Answer 3

Printing EULA from Wix3.0 and later

1) When you compile your wix source code, the light.exe must reference the WixUIExtension.dll in command line. Use the command line switch -ext for this.

2) If when you add the reference to the WixUIExtension.dll, your project fails to compile, this is most likely because of clashes of Dialog IDs, i.e. your project was using the same IDs of dialogs as some standard dialogs in WixUIExtension.dll, give different IDs to your dialogs. This is quite common problem.

3) Your license dialog must have ScrollableText control with the id "LicenseText". Wix searches for exactly this name of control when it prints.

<Control Id="LicenseText" Type="ScrollableText" X="20" Y="60" Width="330" Height="160" Sunken="yes" TabSkip="no">
    <Text SourceFile="License.rtf" />
</Control>

and a PushButton which refers to the custom action

<Control Type="PushButton" Id="PrintButton" Width="57" Height="17" X="19" Y="244" Text="Print">
    <Publish Event="DoAction" Value="PrintEula">1</Publish>
</Control>

4) Define CustomAction with the Id="PrintEula" like this:

<CustomAction Id="PrintEula" BinaryKey="WixUIWixca" DllEntry="PrintEula" Return="ignore" Execute="immediate" />

Note: BinaryKey is different in Wix3.0 comparing to Wix2.0 and must be exactly "WixUIWixca" (case sensitive).

When user presses the button he/she will be presented with the standard Select Printer Dialog and will be able to print from there.

Answer 4

It's a nice structure but based on my experience I wonder how you address these conditions:

A. Your installs all appear to land in the same destination. If a user needs to install all 3 versions at once will your process allow this. Can they unambiguously tell which version of every executable they are triggering?

B. How do you handle new files that exist in TEST and/or TRAINING but not yet in LIVE?

Answer 5

Using Heat.exe to smash face and inflict "Epic Pwnage" on painfully large installs

Expanding on Si's and Robert-P's answers about heat.

Translation: (Using heat to avoid typing individual files into the project by hand and for automating builds for an overall easier process.)

WiX 2.0 Heat Syntax detailed

For newer versions (not all that different from older versions but there are potentially annoying syntax changes....) go to the directory Heat is in from the cmd.exe and just type in heat but I have a example one right here for help with newer versions if needed.

Adding the following to your Build Event in visual studio 2010.
(Right Click Project->Properties ->Build Events-> Pre-Build Events)

$(WIX)bin\heat.exe" dir "$(EnviromentVariable)" -cg GroupVariable -gg -scom -sreg -sfrag - srd -dr INSTALLLOCATION -var env.LogicPath -out "$(FragmentDir)\FileName.wxs

-gg 

Generates Guids when heat is run(as in when you execute the command above)

-scom 

Dont grab "COM files"

-sreg 

Dont grab "Registry Files"

-sfrag 

Dont grab "Fragments"

-srd 

Dont grab the "root Dir"

dir

dir indicates you want Heat to look in a folder

"$(EnviromentVariable)"

The name of the variable you would add to the Preprocessor variables in the (Right click project, Go to properties) project properties->Build section where it says Define preprocessor variables (assumes visual studio 2010)

Example:
EnviromentVariable=C:\Project\bin\Debug;

No double quotes but end with a semicolon

-cg GroupVariable 

The ComponentGroup that will be referenced from the fragment created to the main wxs file

FragmentDir

The fragment directory where the output wxs fragment will be stored

FileName.wxs

The the name of the file

Full tutorial here, So freakin helpful

Part 1 Part 2

Answer 6

Create a UI that has a custom action that will set a variable and the UI will disable/enable the next button (or similar) based upon the variable set in the custom action.

Not as straight-forward as you would think, not too difficult just not documented anywhere!

Wix Interactions with Conditions, Properties & Custom Actions