WiX burn bundle installer - ExePackage not being updated on upgrade install

Question

I'm working on a WiX bootstrapper/bundle installer which installs a MSI package and a few .exe packages. The bundle installer will need to be able to upgrade its components when a new bundle is installed. Initially I faced an issue where my ExePackage components were being un-installed on upgrade, and then I learned that you can avoid that by putting a dep:Provides entry in the ExePackage elements. That fixed the un-install upgrade issue, but now I'm seeing an issue where the ExePackage components are not being upgraded with a newer bundle installer.

I've tested this by creating 2 versions of my bundle installer - One with a newer version of one of the ExePackage components. If I install the lower-version bundle, then install the newer-version bundle, it appears that nothing gets upgraded - The one ExePackage component it's supposed to upgrade is still the older version. The registry entry created by the dep:Provides element gets updated with the new version though. Then, when I un-install the bundle, everything gets removed except for the ExePackage component that it was supposed to upgrade.

It seems there is a lack of documentation or examples for this scenario and others with WiX. Does anyone have an example for this scenario?

One of my ExePackage elements looks similar to this:

<ExePackage Id="BLAH_INSTALLER"
              SourceFile="$(var.SolutionDir)\InputBin\BlahSetup.exe"
              Compressed="yes"
              InstallCommand="/install /quiet"
              UninstallCommand="/uninstall /quiet"
              DetectCondition="BlahPresent"
              Cache="always" >
    <dep:Provides Key="Blah" Version="5.0.0.0" />
  </ExePackage>

My DetectCondition logic is a FileSearch which looks similar to this:

<util:FileSearch
  Id="Blah_Installed"
  Path="[ProgramFiles64Folder]\blah\blah.exe"
  Variable="BlahPresent"
  Result="version" />

Answer 1

Your detect condition needs to be true when that exact version of the package is installed, and false otherwise. So it probably needs to be something like BlahPresent = v5.0.0.0 instead of just BlahPresent (which is true even if a different version is installed).

Answer 2

It seems that the DetectCondition is preventing the .exe packages from being updated. However, the reason I added the DetectCondition was to solve another problem: Without DetectCondition , the bundle installer would not uninstall the .exe packages. So it seems I have to choose between one issue or another - I'm not sure how to solve both issues.

Answer 3

I'm still working on supporting upgrading with EXEPackage so this is a work in progress:

I didn't find the Provides element at first and decided to manage my own registry entries in my bootstrapper. From what I read, what I'm doing in the registry is similar to how Burn handles Provides.

The BootstrapperApplication has a Guid as its build ID. The build ID is new for every build. When installing, bootstrapper creates a PackageID-BuildID pair in the registry for every package (MSI packages don't need this but it doesn't hurt to have entries as well).

Before calling Engine.Detect(), my bootstrapper does it own detection in the registry and passes a single true/false string variable for each EXE package as its DetectCondition. DetectionCondition is only true if the exact same build ID is in the registry (ie an existing outdated package doesn't count as existing package). Disable removing the package if the bootstrapper has an upgrade since the bootstrapper can't distinguish different versions of the same EXE package . Otherwise, the bootstrapper can remove it thinking it's the old version.

Since you didn't mention anything about a custom bootstrapper, I assume you are not writing one. I suppose you can manipulate the registry similarly in the WXS file and associate the entries with your DetectCondition.

The problem I haven't solved is to remove an EXE package during upgrade. Our bootstrapper has a package selection page similar to the feature selection in an MSI. A user should be able to remove an old package without installing a new version by deselecting it. My bootstrapper won't uninstall the package since it doesn't think it exists.

Sorry for the long answer. Happy to chat in the comments if it is still confusing.