WiX woes: What is your installer doing?

Summary: How to detect different modes of installation.

When building an application installer, it's often necessary to distinguish between different modes of installation, i.e. initial installation, repair, upgrade, uninstall, etc. And as with everything important in MSI, detecting the mode of installation is a PITA (and by PITA, I do not mean flat bread of Mediterranean origin). To help you a little bit, here is a table adopted from a StackOverflow topic (and comments), that shows the values of various Windows Installer properties can help you determine the installation mode:

	Install	Uninstall	Repair	Modify	Upgrade
INSTALLED	FALSE	TRUE	FALSE	TRUE	TRUE
REINSTALL	TRUE	FALSE	TRUE	FALSE	FALSE
REMOVE="ALL"	FALSE	TRUE	FALSE	TRUE	TRUE
UPGRADINGPRODUCTCODE	TRUE	FALSE	TRUE	TRUE	TRUE

You can use logical operators NOT, AND, OR to build complex conditions.

Here is how you can detect some common conditions:

First-time installation

• NOT Installed

Any installation

• NOT Installed AND NOT PATCH

Installation and repairs

• NOT REMOVE

First-time installation and repairs

• NOT Installed OR MaintenanceMode="Modify"

Upgrades only (during uninstall phase)

• Installed AND UPGRADINGPRODUCTCODE

Upgrades

• Installed AND NOT REMOVE

Full uninstall (except when triggered by a major upgrade)

• (REMOVE="ALL") AND (NOT UPGRADINGPRODUCTCODE)

Any uninstall

• REMOVE~="ALL"

If you notice errors or want to include some other conditions, please post a comment.

See also:
MSI Property Patterns: Upgrading, FirstInstall and Maintenance
Upgrading, FreshInstall, Maintenance and other MSI convenience properties
MSI Writing Guidelines: Installation Scenarios
How to execute custom action only in install (not uninstall)

Build 32- and 64-bit installers using WiX

Summary: Code samples illustrating how to build deployment packages for both x86 and x64 platforms from the same Windows Installer XML (WiX) project.

This is post #6 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

My recent post offers code samples illustrating a life cycle and core features of a WiX deployment project. The samples miss one important aspect: target platforms (i.e. x86 vs x64). While the samples get installed and run fine on both 64-bit and 32-bit platforms, the deployed applications always appear as 32-bit programs, even though they run as 64-bit processes on 64-bit machines (all assemblies are compiled to run on Any CPU).

I tried to add 64-bit support to the existing projects, but ran into several issues (e.g. folder selection wizard always showed the wrong Program Files folder on 64-bit systems). It took me a few weeks to resolve the problems, so here are the updated projects (all projects use Visual Studio 2010):

• Download WiX demo projects (64-bit and 32-bit)

These samples do everything the original samples do, plus:

• Solutions include build targets for 64-bit platforms: Debug (x64) and Release (x64).
• WiX projects can build 64-bit MSI files (via 64-bit build targets).
• Build process renames MSI files to indicate target platforms and copies them to a separate MSI folder under the WiX project (in a post-build event).
• Detect and use the original application folder during upgrades.

Here is what you need to do to build installers for 32- and 64-bit platforms:

• Understand the differences between 32- and 64-bit installers.
  At the very least, you need to understand that a setup package (MSI file) file can be marked as either a 32- or 64-bit installer (64-bit installer cannot run on 32-bit systems, but it can install 32-bit components on 64-bit systems). The following article can give you a basic idea of intricacies related to 64-bit platform deployment: How Windows Installer Processes Packages on 64-bit Windows (see also other relevant articles).
  
  
• Add the x64 build target to your WiX setup project.
  Assuming that all application assemblies (and support files) are not platform-specific, keep their build configuration marked as Any CPU, but add new configurations to the WiX setup project and associate it with the x64 platform; make sure configuration names identify the 64-bit platform, e.g. Debug (x64) and Release (x64).
  
  
  Tip: I often run into problems adding a new configuration via Visual Studio IDE. E.g. sometimes, I cannot add the x64 platform to some projects, or I would add it, but when I close the Configuration Manager dialog box, my settings would disappear. If you run into such issues, I suggest making changes directly to the project (.wixproj) and solution (.sln) files (their structure should be obvious). [Notice that you can edit a project file directly in the Visual Studio IDE by unloading and reloading the project.] Then open the Configuration Manager dialog box (via the Build - Configuration Manager menu), and make sure your project build mappings looks right.
  Your configuration settings should look similar to this:
  
  
  
  The idea here is that you always build your platform-independent assemblies for Any CPU and only use x86 and x64 targets for the setup projects (or any platform-specific project).
  
  
• Define and use platform-specific properties in the WiX source (.wxs) file.
  It's a good idea to have platform-specific GUIDs for product ID and upgrade code, as well as product name. You should always use a variable to store platform-specific Win64 flag and folder names (such as Program Files folder). Here is the code that illustrates how to achieve this:
  

  <?define ProductName = "WiX Demo" ?>
  <?define ProductVersion = "1.0" ?>
  <?define ProductFullVersion = "1.0.0.0" ?>
  <?define ProductAuthor = "Alek Davis" ?>
  <?define ProductAppFolder = "InstallLocation" ?>
  
  <?if $(var.Platform) = x64 ?>
    <?define ProductDisplayName = "$(var.ProductName) 64-bit" ?>
    <?define ProductId = "47861F89-765F-4D6D-BEDE-139F0BCD74ED" ?>
    <?define ProductUpgradeCode = "EE2511C1-75A7-4954-8AB6-0E405C9481B4" ?>
    <?define Win64 = "yes" ?>
    <?define PlatformProgramFilesFolder = "ProgramFiles64Folder" ?>
  <?else ?>
    <?define ProductDisplayName = "$(var.ProductName)" ?>
    <?define ProductId = "490CCCF1-54C3-4AC2-8C88-A8903556EEB3" ?>
    <?define ProductUpgradeCode = "E7E6A7CB-1D12-486D-9E53-DBC56B0EDDCB" ?>
    <?define Win64 = "no" ?>
    <?define PlatformProgramFilesFolder = "ProgramFilesFolder" ?>
  <?endif ?>

  The code above tells the WiX compiler to check the value of the build platform property $(var.Platform). If the compiler detects the x64 build platform target, it will set platform-dependent variables to 64-bit specific values; otherwise, it'll use 32-bit values.
  
  
• Use platform-specific properties to set element attributes.
  Now you can use platform-specific properties set by WiX compiler instead of hard-coded values:
  

  <Product 
    Id="$(var.ProductId)" 
    Name="$(var.ProductDisplayName) (v$(var.ProductVersion))" 
    Language="1033" 
    Version="$(var.ProductFullVersion)" 
    Manufacturer="$(var.ProductAuthor)"
    UpgradeCode="$(var.ProductUpgradeCode)">
  
    <Package 
      InstallerVersion="300" 
      Compressed="yes" 
      InstallScope="perMachine" 
      Manufacturer="$(var.ProductAuthor)" 
      Platform="$(var.Platform)" />
    ...
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="$(var.PlatformProgramFilesFolder)" >
        <Directory Id="APPLICATIONFOLDER" Name="$(var.ProductName)"/>
      </Directory>
    ...
    </Directory>
    ...
  </Product>

• Set platform flag on components.
  Make sure that all of your product components are marked with the appropriate Win64 flag. Use a variable (like $(var.Win64) defined in the code sample above) to change the value dynamically based on the build platform, such as:
  

  <Component
    ... 
    Win64="$(var.Win64)">
    ...
  </Component>

  If you have components which must be deployed only on 32- or 64-bit platform, you can hard-code their Win64 attribute values and conditionally include or exclude them based on the build target:
  

  <?if $(var.Platform) = x64 ?>
    <!-- 64-bit components go here -->
  <?else ?>
    <!-- 32-bit components go here -->
  <?endif ?>

• Rename MSI files to indicate target platform.
  You can define a post-build step to rename your MSI files, so that they reflect the intended platform. Select the Project - Properties menu; in the Build Events tab, set the Post-build Event Command Line to something like this:
  

  if not exist "$(ProjectDir)msi" mkdir  "$(ProjectDir)msi"
  copy "!(TargetPath)" "$(ProjectDir)msi\$(TargetName)($(PlatformName))$(TargetExt)" /Y /V

  These commands rename and copy the output MSI file to the MSI folder (in the project directory). They will create the folder if it does not exist. The file name will contain the (x86) or (x64) suffix depending in the target platform (e.g. WixDemo1.0(x64).msi).
  

That's about it. Oh, almost forgot: test, test, test...

See also:
Walking through the creation of a complex installer package by Gabriel Schenker

Beginner’s guide to Windows Installer XML (WiX) 3.5

Summary: Slides and demo projects.

This is post #5 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

I just updated and uploaded the slides from the presentation I gave to my work group yesterday (you can download the PowerPoint [PPTX] presentation from the SlideShare site):

You can also download the demo projects.

There are three demo solutions, each containing four projects, all implemented in Visual Studio 2010 (you also need WiX 3.5 Toolset/Votive):

• A client (Windows Forms) application.
• A server (Windows service) application.
• A class library (DLL used by both client and server).
• A WiX 3.5 setup project handling deployment of the client, server, and class library.

The demo apps (client, server, library) don't do much (they are there only for the WiX project). The WiX setup project illustrates how to accomplish the following:

• Install and configure a Windows service.
• Install a client application.
• Install a class library in Global Assembly Cache (GAC).
• Install a text (readme.txt) file.
• Create shortcuts under the Start menu for the client app and text file.
• Create a shortcut under the Start menu for the application uninstaller.
• Display the advanced setup dialog sequence (wizards) allowing the user to select the installation scope (per user or per machine), specify product destination folder, chose which features to install (client, server, or both).
• Perform major upgrades (upgrades will retain Windows service definition for the already installed server component).
• Include application files in the setup package via project references (instead of hard coding the file names).

The three solutions illustrate a typical life cycle of a project. First, you build and deploy version 1.0. Then you can build and deploy version 1.5. The version 1.5 installer will upgrade the already installed version (you don't need to uninstall version 1.0 before installing version 1.5). Then you can do the same for version 2.0. Notice that installers preserve Windows service configuration during upgrades (if you redefine the service to run as a specific user instead of a local system account, the service configuration will remain intact).

UPDATE: See new and improved samples, which explain how to implement installers for 32- and 64-bit targets and do other things.

I'd also like to recommend two books which I found extremely helpful: WiX: A Developer's Guide to Windows Installer XML by Nick Ramirez covers WiX; The Definitive Guide to Windows Installer (Expert's Voice in Net) by Phil Wilson - general Windows Installer (MSI) concept:
And one more thank you to Jeffrey Sharp for his excellent WiX presentation (you can get the slides and watch Jeff's talk online).

See also:
My three-part introduction to WiX series

WiX how-tos and missing links

Summary: Links to articles explaining how to accomplish different tasks in WiX and other helpful information.

This is post #4 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

Here is a list of articles covering topics that I either did not find -- or found implemented better than described -- in most popular WiX tutorials and wikis:

How to: Exclude license agreement dialog from the dialog sequence
How to: Install a Windows service (see also this and that)
How to: Build 32-bit and 64-bit MSI packages (see this thread, and that one, too)
How to: Add a shortcut (without an icon [.ICO] file)
How to: Add a checkbox to conditionally install a desktop shortcut (via a check box)
How to: Add a desktop shortcut (without a registry key)
How to: Create shortcuts for ALL USERS
How to: Execute custom action (CA) on uninstall only
How to: Create an uninstall shortcut
How to: Launch program after installation
How to: Add a neat checkbox to the exit dialog for launching a program or help file
How to: Create a localized installer and bootstrapper (see also parts 2, 3, and 4)
How to: Modify XML files (e.g. web.config) during installation
How to: Modify web.config file during installation (turn off debug flag, etc)
How to: Implement custom actions (CAs) (excellent explanation of different CA types)
How to: Implement a custom action in managed code (C#/VB.NET)
How to: Implement a major upgrade (see Brian Gillespie's comment for optimization ideas)
How to: Preserve original Windows service configuration on major upgrade
How to: Deploy a web site (also this one)
How to: Save path to installation folder in the registry (search for ARPINSTALLLOCATION; see also this, this, and that)
How to: Override (wrong) Program Files (x86) on x64 machines in WixUI_Advanced sequence
How to: Upgrade application in the original installation folder ()
How to: Make setup UI sequence show only two (Welcome and Final) dialog boxes
How to: Retain user-customized files during a Windows Installer major upgrade
How to: Register a COM+ application
How to: Create an event log source
How to: Deploy publisher policy files to GAC

I also found the following information very insightful (some related to MSI, other about WiX):

Description of TARGETDIR and SourceDir
Explanation of the MergeRedirectFolder variable
Differences between 32-bit, 64-bit, and mixed MSI packages (includes folder locations, package compatibility and other info)
How Windows Installer Processes Packages on 64-bit Windows
List of system folders defined by the Windows Installer engine
Add/Remove Programs (ARP) support (good explanation and illustration of ARP properties)
Windows Installer: Property Reference
MSI Writing Guidelines

I will keep updating these lists updated when I find more useful articles.

See also:
WiX - Windows Installer XML (more how-tos)
WiX tricks and tips (includes a few how-tos)
WiX Tricks (several good suggestions)
WiX Tips & Tricks

Learning WiX from ground up

Summary: Reference guide for beginners.

This is post #3 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

So you decided to create your first setup package using Window Installer XML (WiX). Where do you start? And how much do you need to know about WiX and Windows Installer (MSI) to build a working deployment package?

The answer to the second question is: it depends. Well... sort of. Before you begin, you definitely need to know the fundamentals of the Windows Installer (MSI) technology, such as:

• The overall structure of an MSI package (MSI database)
• The difference between packages, features, components, and deployment items (files, registry keys, shortcuts, etc)
• Custom actions (CAs) and how they are used
• Upgrade types (minor vs. major upgrade)
• Merge modules

You don't need the in-depth knowledge, but at the very least, you need to understand the terminology (check the Wikipedia overview and MSI Basics). You may need to learn more to implement such complex features as program shortcuts (yes, shortcuts are complex in Windows Installer), but you will be able to learn additional concepts as you go.

To get started, install the current version of WiX Toolset from:

• Wix Toolset Codeplex Distribution

You can download a beta version of the upcoming release or an older version of WiX Toolset from SourceForge.

I assume that you will be using Visual Studio to develop setup programs. WiX Toolset includes a Visual Studio add-on, Votive, that enables WiX integration with the Visual Studio IDE. After installing WiX Toolset, make sure that WiX project templates appear in the New Project dialog box:

At this point, you can create a WiX project, but when you open the auto-generated WiX source file, you'll realize that you have no idea what to do with it. This is where a tutorial can help.

The WiX Toolset's help file is a good place to start (by default, the help file is installed to C:\Program Files\Windows Installer XML v3\doc\wix.chm; you can find a shortcut to the help document under the WiX program group in the Start menu; the help file can be also viewed online). You don't need to read it all; the first few chapters and how-to articles give you a basic idea of what you need to do to get a functional setup project.

To get more in-depth understanding of WiX, check out more advanced tutorials. The ones I found most helpful include:

• WiX Tutorial by Gábor DEÁK JAHN, Tramontána (official WiX tutorial; a lot of good info, but can be overwhelming)
• Yet Another WiX Tutorial by Rennie Petersen (addresses fewer topics, but in more depth)
• From MSI to WiX by Alex Shevchuk (excellent information helping understand both MSI and WiX)
• WiX Tutorial by r0k0t (awkward format, but great info presented as lessons)
• WiX Wiki (I din't use it much, but noticed a few articles that could be helpful)
• WiX tricks and tips (wiki post at StackOverflow with many good suggestions)
• Creating an installer using Wix v3.0, Votive, and Visual Studio 2005/2008 (simple demo; see also Part 2: the GUI)

There is also a very insightful presentation by Jeffrey Sharp (with slides and video):

• Talk: Setup With Windows Installer and WiX

The following MSDN article by Ibrahim Hashimi is a bit out-of-date and has a slightly different focus (build automation), but it still offers a pretty decent overview of WiX:

• Automate Releases With MSBuild And Windows Installer XML

Nick Ramirez just published an excellent book that covers a lot of WiX and Windows Installer (MSI) topics (see my Amazon review):

• WiX: A Developer's Guide to Windows Installer XML
  

You can read the Getting Started and Adding a User Interface chapters online.

And here is a list of tools that you may want to check out:

• SharpSetup creates bootstrapper and GUI for your WiX installer in C# and WinForms.
• Wix# (WiXSharp) builds MSI packages or WiX source code from C# code.
• IsWix (Industrial Strength Windows Installer XML) is a document editor that enables non-setup developers to collaborate with setup developers using WiX projects.
• WixEdit is an editor for XML source files for the Windows Installer XML (WiX) toolset to build MSI and MSM setup packages.

After you feel more comfortable with WiX basics (deploying files, etc), your next challenge will be implementing slightly less obvious operations (registering COM objects, creating shortcuts, using custom actions, etc) that are either not covered in the help file and popular tutorials or covered incompletely. In the next post, I will include the list of references to the how-to articles that I found most helpful.

Introduction to WiX

Summary: Answers to most likely questions from Windows Installer XML (WiX) novices.

This is post #2 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

Here is a list of questions I had a couple of weeks ago before I started working with WiX (Windows Installer XML). I hope that answers to these questions will help other WiX novices.

What is WiX?
WiX is a language (Windows Installer XML [eXtensible Markup Language]), or more specifically, a Windows Installer-specific XML syntax. You can use WiX syntax to author XML source files for your setup project, from which you can then build Windows Installer (MSI) packages with the help of WiX Toolset.

What is WiX Toolset?
WiX is distributed as a free (open-source) toolkit that includes several command-line tools (such as WiX compiler, linker, etc), documentation, and utilities. Once you create WiX source files defining your setup application (you can do it by hand in a text editor, such as Notepad), you can use WiX Toolset to compile these files into a Windows Installer (MSI) package.

Can I develop WiX projects in Visual Studio?
Yes, WiX Toolset's Visual Studio package, Votive, which is also free (and open-source), adds WiX-specific project templates to Visual Studio, so you can create and build WiX projects directly from Visual Studio. Votive also provides syntax highlighting and IntelliSense for WiX source files.

Which version of Votive do I need?
There are several versions of Votive (and WiX Toolset), each targeting specific versions of Visual Studio. At the time of writing, the latest version (v3.5 for Visual Studio 2010) was still in beta. The recommended version (v3.0) works with both Visual Studio 2008 and 2005. Earlier version(s) of the toolset target the earlier version(s) of Visual Studio.

How does Votive/WiX differ from Visual Studio Installer?
Visual Studio Installer (or Setup and Deployment Project Template) allowed you to build setup packages via drag-and-drop activities and automation. It automatically detected dependencies for your application files, generated GUIDs for components and features, and did a few other things in the background, so you may have not even realized that they were happening. When working with WiX projects you must perform all these tasks by hand.

So WiX is not as good as Visual Studio Installer, right?
Yes, and no. It's true that WiX requires more manual work. And it has a steep learning curve. But it's more flexible than Visual Studio Installer, it supports more features and customization, and gives you more control over the resulting setup package. And it produces a much cleaner MSI database.

Does WiX support all features of Windows Installer?
No, unfortunately not. WiX supports many common features of Windows Installer technology, but not all. The list of supported features includes (but is not limited to):

• 32-bit, 64-bit, and mixed (32/64-bit) installers
• Creation of shortcuts and registry entries
• COM server registration
• Windows service registration
• Customization of setup dialog sequence (up to certain extent)
• Creation of web sites
• And much more

If you wonder about WiX support of a particular feature, check the web for articles and posts on the topic of your interest and you're most likely to find whether WiX support it or not.

Can I use WiX to create a bootstrapper program (setup.exe)?
No, WiX Toolset only allows you to build MSI and MSM (merge module) files.

What are other limitations of WiX?
See the answers posted on StackOverflow.

What are the differences between WiX project types?
In addition to regular installer projects, Votive allows you to build merge modules and WiX libraries. Merge modules let you share installable components among different products. For example, if you want to deploy a common COM component/ActiveX control with different applications, you can encapsulates its installer in a merge module and than use this merge module with regular WiX installer projects (the merge module will be absorbed in each product's MSI package). WiX libraries allow you to share identical sections of XML code between the WiX source files (this is similar to using include files in C/C++ projects).

What do I need to know before learning WiX?
In theory, you should understand Windows Installer (MSI) before you start learning WiX, but in practice you can learn both technologies concurrently. The abundant information available online can help you get started and achieve progress even if you have very limited understanding of Windows Installer.

Where do I find support if I get stuck?
You can start at StackOverflow (I found answer to most of my questions there). The "official" support site is at SourceForge.

I want to try WiX. Where do I start?
This will be the topic of my next post.

See also:
What about that WiX?
Dude, where is your installer?

What about that WiX?

Summary: Reflections from my first encounter with Windows Installer XML (WiX).

This is post #1 of the six-part Learning WiX series. For other topics, see:

Table of contents

1. Background (why WiX?)
2. Introduction (answers to common questions)
3. Getting started (references and tutorials)
4. How-to's and missing links
5. Slides and demo projects
6. Improved demo projects (32- and 64-bit installers)

There comes a time in every Windows programmer's life to face WiX (Windows Installer XML). For me this time came with the news of Microsoft's plan to retire Visual Studio Installer in favor of InstallShield Limited Edition. So I spent the last couple of weeks getting to know WiX and using it to implement installers for several production applications. This is what I learned.

Good news: (1) WiX Toolset let me create installers that were on par with installers I used to build in the good ol' pre-Windows Installer days. (2) I did not have a panic attack when I opened the WiX-generated MSI files in Orca (WiX seem to produce less garbage than say Visual Studio Installer). (3) It took relatively few lines of XML code to build an installer that handled deployment of a Windows service, COM object registration, desktop and shortcut menu creation, invocation of a configuration utility, and typical user interface (setup wizard).

Unfortunately, I cannot say that my transition to WiX was seamless. WiX Toolset has a few limitations. To be fair, some of these limitations are caused by idiosyncrasies imposed by Windows Installer (MSI), but some are native to WiX (e.g. it seems impossible to use the recommended type of custom action when invoking an executable from a merge module). WiX tools sometimes lack features (e.g. it's relatively easy to extract COM registration information from a COM DLL, but there is absolutely no way to do it from a COM executable). There are bugs (probably not as obnoxious as InstallShield bugs, but still). Project documentation and information is skimpy and somewhat confusing (why is the project split between SourceForge and CodePlex? how long should it take a WiX novice to figure out what and how to download the toolkit? why is it called Votive? and why is "i" in "WiX" lower case?) And the WiX learning curve is rather steep, especially for those who have not been intimate with Windows Installer (MSI).

One good -- and bad -- thing about WiX is that it's an open-source project. On the positive side, WiX has a momentum now both inside and outside of Microsoft. On the other hand, it's not clear if, or how long, Microsoft's backing of the project will continue (say, Microsoft strikes another back room deal [I'm speculating here] with Flexera [the InstallShield maker] and withdraws all support from WiX).

As long as you are looking for alternatives, here is a list of commercial products that can help you build MSI-based installers:

• InstallShield by Flexera Software
• Wise Installation Studio by Altiris, Inc/Symantec
• InstallAware for Windows Installer by InstallAware Software
• Advanced Installer by Caphyon
• MSI Factory by IndigoRose Software Design Corp.
• Tarma InstallMate by Tarma Software Research
• See also List of installation software (Wikipedia)

Some of these are more popular than others (popularity is often an indicator of the size of the marketing budget than product quality), but I haven't use them to extent of recommending one over the other. [I used to be a huge fan of InstallShield in the late 90's, but after the InstallShield 7 migration fiasco (3 months wasted on a failed attempt to convert a complex InstallShield 6.x project to InstallShield 7, mostly due to bugs in the product) I would not want to re-live the pain.] So for the time being I will stick with WiX.

If you are interested in WiX, read my subsequent posts. I will share (time permits) the things that helped me get started. Here is the outline of the upcoming WiX-related posts (I'll convert items to hyperlinks when the posts are ready):

2. Introduction to WiX (FAQs for novices)
3. Learning WiX from ground up (resources for WiX beginners)
4. WiX how-tos and missing links (helpful how-tos and insights)
5. Bonus: Presentation and demo projects
6. Extra bonus: Build 32- and 64-bit installers using WiX (new and improved samples)

See also:
Choosing a Windows Installer Deployment Tool
Dude, where is your installer?
Rob Mensching Does Installations with the WiX Toolset (podcast, transcript)