Skip to content

Choosing your payloads

WiX provides two ways of identifying a setup package’s payload – the files that are included in the setup and installed on the user’s machine. 

  • By file name and directory tree.
  • By explicit source file.

Compiling, linking, and binding

The WiX toolset models a typical C/C++ compiler is how authored is built, with a compiler that parses the WiX source authoring to object files and a linker that combines the object files into an output. For WiX, the output is an .msi package, .msm merge module, or .wixlib library, which have a third phase: binding payload files into the output. Light.exe includes both the linker and binder.

Though WiX source authoring refers to payload files, the compiler never looks at them; instead, only the binder does, when it creates cabinets containing them or copies them to an uncompressed layout.

You can provide the binder with one or more base input paths it uses to look for files. It also looks for files relative to the current working directory. Light.exe’s –b switch and the BaseInputPaths .wixproj property let you specify one or more base input paths.

Identifying files by name and directory tree

When you use the File/@Name attribute and don’t use the File/@Source attribute, the compiler constructs an implicit path to the file based on the file’s parent component directory plus the name you supply. So, for example, given the partial authoring

<Directory Id="TARGETDIR">
  <Directory Name="foo">
    <Directory Name="bar">
      <Component>
        <File Name="baz.txt" />

the binder looks for a file foo\bar\baz.txt in the base input paths.

Overriding implicit payload directories

The FileSource attribute for the Directory and DirectoryRef elements sets a new directory for files in that directory or any child directories. For example, given the partial authoring

<Directory Id="TARGETDIR">
  <Directory Name="foo" FileSource="build\retail\x86"> 
    <Directory Name="bar">
      <Component>
        <File Name="baz.txt" />

the binder looks for a file build\retail\x86\bar\baz.txt in the base input paths.

The FileSource attribute can use preprocessor variables or environment variables. If the value is an absolute path, the binder’s base input paths aren’t used.

Preferred use

If the build tree serving as your payload source is almost identical to the tree of your installed image and you have a moderate-to-deep directory tree, using implicit paths will avoid repetition in your authoring.

Source directories

The Directory/@SourceName attribute controls both the name of the directory where Light.exe looks for files and the "source directory" in the .msi package. Unless you also want to control the source directory, just use FileSource.

Identifying payload by source files

The File/@Source attribute is a path to the payload file. It can be an absolute path or relative to any base input path. If File/@Source is present, it takes precedence over the implicit path created by Directory/@Name, Directory/@FileSource, and File/@Name.

If you specify File/@Source, you can omit File/@Name because the compiler automatically sets it to the filename portion of the source path.

Preferred use

If the build tree serving as your payload source is different from the tree of your installed image, using File/@Source makes it easy to pick explicit paths than are different than the .msi package’s directory tree. You can use multiple base input paths to shorten the File/@Source paths.

For example, the WiX setup .wixproj project points to the output tree for the x86, x64, and ia64 platforms WiX supports and the WiX source tree. Unique filenames can be referred to with just their filenames; files with the same name across platforms use relative paths.

See the WiX authoring in src\Setup\*.wxs for examples.

Paying for upgrades

No, this isn’t a post on the costs of proprietary software but an amplification/clarification to my previous post. On wix-users, there’s a thread on the pains of automating upgrades.

If your product consists of a large number of files and the file set changes regularly – files being added and removed during the product lifetime – it’s only natural to want to avoid the cost of hand-authoring setup changes to match. (A little over a year ago, I shipped a product with over 7000 files, so I’m familiar with the pain and desire for automation.)

Unfortunately, our frenemy the component rules makes such automation difficult. The closest we-the-WiX-team has gotten to a complete solution is to create components with one file each, which makes the component eligible to have its component GUID automatically generated (using an asterisk in the Component element’s Guid attribute value).

What doesn’t work is when files are removed. Windows Installer doesn’t let you remove components in a minor upgrade, so using one file per component doesn’t immediately solve the automation problem: Your automatically-generated minor upgrade will be missing a component, which is a mortal component-rule sin.

Nor can you avoid the problem by using multiple components per file because component rules say that components must be immutable: You can’t add or remove resources from a component.

So automating the creation of minor upgrades has additional costs:

  • Additional tooling to try to support removing files without blatantly violating component rules.
  • Additional coding in your product to tolerate "obsolete" files without being able to remove them.

For many types of apps, but especially Web apps with many content files, that’s a huge cost. Being able to ship minor-upgrade patches from an automated build might be a benefit worth the cost. It’s really a decision your team needs to make.

I’ll add that if you don’t anticipate shipping patches on a regular schedule, you might just automate the authoring of your RTM product and pay the price of manually tweaking your setup authoring when you need to ship a patch. Again, it’s a cost-benefit decision your team needs to think about.

Cheap and easy

If you don’t absolutely need to ship patches, you can avoid the costs of minor upgrades by simply using major upgrades. You can remove files without worrying about component-rule violations if you use an "early" scheduling of the RemoveExistingProducts standard action – before or immediately after the InstallInitialize action.

The MSI SDK notes that scheduling RemoveExistingProducts early is "inefficient" because the files that are same between the two product versions are removed and then reinstalled. But that inefficiency is what lets you remove files and components. If you schedule RemoveExistingProducts immediately before or after InstallFinalize, MSI implements the major upgrade by installing the new version of the product "on top of" the previous version, upgrading files with newer versions, then removing the previous version. MSI increments the reference count of components in both packages during the installation of the newer version, then decrements it during the removal of the previous version. Component reference counting works only if component rules are followed, so it’s pretty much the same as minor upgrades.

If you have a large product, the size and install-time benefits of minor upgrade patches might be worth the development effort. Otherwise, major upgrades scheduled early are a great solution. Your call.

Neither more nor less

‘When I use a word,’ Humpty Dumpty said, in a rather scornful tone,’ it means just what I choose it to mean, neither more nor less.’

‘The question is,’ said Alice, ‘whether you can make words mean so many different things.’

‘The question is,’ said Humpty Dumpty, ‘which is to be master - that’s all.’

Alice’s Adventures in Wonderland and brought to mind by almost anybody reading SDK documentation for any length of time

Windows Installer has three ways of upgrading products from one version to another:

  • Major upgrades
  • Minor upgrades
  • Small updates

There are two common problems we run into when discussing upgrades given size-related terms to describe upgrades.

Version numbers

Major and minor are also commonly used to refer to particular elements in a version number (major.minor.build.patchlevel being most common).

But major upgrades can upgrade any product version number to any other version number, regardless of which parts of the version number change. For example, the WiX installers are always major upgrades for every 3.0.xxxx version; only the build portion of the version number changes with each weekly build. And the WiX v3.0 installers don’t do major upgrades down to WiX v2; we intentionally designed the installers to be able to live "side-by-side" on the same system to help migrating from WiX v2 to v3.

Minor upgrades, on the other hand, are usually used to deliver service packs; they must change some part of the product version but can’t change the major part of the product version (at least according to PatchWiz.dll error ERROR_PCW_INVALID_MAJOR_VERSION).

Small updates cannot change the product version at all.

Size matters not

Major, minor, and small also bring to mind size or breadth of a particular upgrade. To an extent, that’s true: Small updates tend to be for single-purpose "hotfix" types of fixes. Minor upgrades can update many files but can make only limited "structural" changes such as adding features and components; they can’t be used to remove components.

Major upgrades aren’t so limited: They can change anything in a product, but also support as few changes as a small update. So even if you’re changing only a few files, you can still use major upgrades. Think of major as an upper limit on the set of changes, not the lower limit on the type of upgrade you need.

Major upgrades also have the advantage of built-in support in Windows Installer. Using Upgrade and UpgradeVersion elements, you can use a "naked" .msi package to install a product for the first time or by major-upgrading a prior version of the product. Doing the same thing with a minor upgrade requires a bootstrapper executable or extra work to set the REINSTALL and REINSTALLMODE properties appropriately.

Highlights of WiX v3.0.4827.0

WiX v3.0.4827.0 was released on Saturday, 27-December-08. You can download it from http://wix.sourceforge.net/releases/3.0.4827.0/.

v3.0.4813.0 is the second post-beta build of WiX v3.0. There are 38 v3.0 bugs still open in the bug tracker.

New features

Bug fixes

Highlights of WiX v3.0.4813.0

WiX v3.0.4813.0 was released on Saturday, 13-December-08. You can download it from http://wix.sourceforge.net/releases/3.0.4813.0/.

v3.0.4813.0 is the first post-beta build of WiX v3.0. There are 47 v3.0 bugs open in the bug tracker.

New features

  • Heath added the NETFRAMEWORK20INSTALLROOTDIR64 property to get the installation directory of the 64-bit .NET Framework.
  • Chris added support for applying patches via the setupexe “baby chainer.”

Bug fixes