1

I am using bootstrapper to include a single MSI. If I have installed the bundle, then re-install by start the bundle EXE, it can detect that bundle has been installed. However, if I rebuild the solution, even no single line code changed, the bundle setup EXE will not detect that bundle has been installed, instead it will install a new version (duplicate entry created in Program and Feature table), but skips to install the MSI. If I start the MSI it will detect same package has been installed. This cause big problem since I have daily build job to build the installer with application, so it cannot detect if the same version has been installed or not. The burn config is simple

<Bundle Name="ProductName" Version="1.0.0.0" Manufacturer="CompanyName" 
      UpgradeCode="28485414-29d0-4b3d-ba8c-33b5f993dfc3">
<BootstrapperApplicationRef   Id="WixStandardBootstrapperApplication.HyperlinkSidebarLicense">
  <bal:WixStandardBootstrapperApplication
    LicenseUrl=""
    LogoFile="..\Resources\Icon\small.png"
    ShowVersion="yes"
    SuppressOptionsUI="yes"
    LogoSideFile="..\Resources\Icon\banner-side.bmp"
    LocalizationFile="HyperlinkTheme.wxl"
    xmlns:bal="http://schemas.microsoft.com/wix/BalExtension" />
</BootstrapperApplicationRef>
    <Chain>
  <MsiPackage SourceFile="$(var.Installer.TargetPath)" Id="MsiEnUs" DisplayInternalUI="yes"/>
    </Chain>
</Bundle>

And the MSI package is define as

    <Product Id="*" Name="$(var.ProductDisplayName)" Language="1033" Version="$(var.ProductVersion)" Manufacturer="$(var.CompanyName)" UpgradeCode="c1b3c617-0af8-4df8-8dff-e893f7bbb30a">
<Package InstallerVersion="200" Compressed="yes"  Platform="x64"  InstallPrivileges="elevated"  InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />

Check the log, I can find that the WixBundleInstalled is 0.

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
John
  • 43
  • 5

1 Answers1

3

WixBundleInstalled refers to this executing bundle. Everytime you rebuild you are generating a new bundle with the same upgrade code. This behaviour is much like the Product Id in the MSI. You can see what this GUID is when you run your bootstrapper and the bootstrapper will extract some information into the %temp% directory into folders named with GUID values that represent the bootstrapper itself.

When you're looking at WixBundleInstalled, the installer actually checks a registry location

SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{ThisBundleGUID} for the "Installed" key and checks that its value is 1.

Every new build of your bootstrapper you do generates a new GUID for that specific bundle exe.

The issue you're running into is that by default wix burn bootstrappers do not support same version upgrades. Instead they will install side by side with the other bootstrapper of the same version. You can modify your bootstrapper code to 'support' this feature but the generally accepted and less error prone method of avoiding this is to implement proper versioning of your bundles by incrementing part of the version every build.

Do note that WiX Burn Bootstrappers do compare versions up to the 4th parts where Window MSI ignores the 4th part.

Brian Sutherland
  • 4,698
  • 14
  • 16
  • Thank you for the answer. That explains burn *does* generate a new GUID every time it gets compiled. However, I still have questions: 1. Is it to provide a GUID in burn like for MSI? 2. When use MSI (I had use dark to extract MSI from the EXE) to install, it actually fails to install, but when use EXE it skips the MSI installation. Is this possible to report that MSI is not installed at all? – John Feb 24 '17 at 01:35
  • 1. The GUID I believe is uncontrollable unless you want to rewrite burn.exe but I am not sure how it is actually generated, I did t a bit of searching but couldn't figure it out. 2. If you are not building the MSI everytime you build the bootstrapper it is the exact same MSI packaged in each install and in this case, not installing it is the correct behaviour. You can view the logs of the bootstrapper run in %temp% and see the detection, plan, and execute phases of the install and what it plans to do with packages defined in the bootstrapper. – Brian Sutherland Feb 24 '17 at 14:59
  • Thanks. I will use build number to distinguish the build. MSI is rebuilt each time as well but I guess it has has GUID so it knows is same product/same version. – John Feb 24 '17 at 17:49