14

I have an application packaged with MSI that is made into a WiX bundle together with various required third-party tools. I have disabled modify and repair actions in the MSI du to how the application works, to require full uninstall before installing the same version again.

When I run the MSI separately, it works as expected: the installer cannot be run twice. The same applies when running the exact same Bundle again. But simply by rebuilding the bundle (using same UpgradeCodeand Version), the installation instead proceeds (much faster this time), and I end up with a duplicate entry among installed programs. I really would like to prevent that and make the bundle work as the MSI.

I have tried with various conditions set on the bundle; NOT WixBundleInstalled, WixBundleInstalled != 1, etc. But none of that seems to work.

For reference, here's the bundle statement:

<Bundle UpgradeCode="{FAF9CBDD-BE89-4B18-9921-FD5B426B5B0C}" IconSourceFile="$(var.SolutionDir)Resources\product.ico" 
          Name="Product 4.4" Version="4.4.0.0" Manufacturer="My Company" DisableModify="yes" Condition="NOT (WixBundleInstalled = 1)">
Torbjörn Bergstedt
  • 3,359
  • 2
  • 21
  • 30
  • 1
    I know a case when this can occur when you install a msi (not a bundle) : if 2 msi have same upgrade code but are installed in different contexts (one installs per-user and the other one per-machine), then there will be no upgrade, ie you will have 2 duplicate entries. – Brainless May 22 '14 at 01:00
  • Thanks. Except our own MSI, there is one externally retrieved (pre-built) MSI that we include in the bundle. I tried adding `ForcePerMachine="yes"` to that `MSIPackage` statement, but that din't help. – Torbjörn Bergstedt May 22 '14 at 14:31
  • is your Product id="*"? – ColacX Oct 01 '14 at 13:57
  • No, we use a unique GUID for each separate "version" of the product. But the problem is not with the product but with the bundle. Anyhow, we have come to the conclusion that this is standard behavior for Wix Bundle, and that we will need to build our own bootstrapper to fulfill our specific requirements. – Torbjörn Bergstedt Oct 02 '14 at 06:19
  • 3
    The multiple entries in **Add/Remove Programs** are caused by the burn engine not supporting same version upgrades. See http://wixtoolset.org/issues/3746/ for more information. – bradfordrg Jun 19 '15 at 08:03

2 Answers2

2

If you add the OptionalUpdateRegistration tag, you will gain an entry in the registry you can use as an InstallCondition for your MSI package

<OptionalUpdateRegistration ProductFamily="MyProductFamily" Name="MyAppBundle"/>

<util:RegistrySearch Id="SearchForMyProduct" 
                     Root="HKLM" 
                     Key="SOFTWARE\WOW6432NODE\MyCompany\Updates\MyProductFamily\MyAppBundle" 
                     Value="PackageVersion" 
                     Result="exists" />

<MsiPackage Id="MyMsi"
            InstallCondition=SearchForMyProduct
            DisplayName="My Wonderful Product"
            SourceFile="MyProduct.msi"
            ForcePerMachine="yes"/>

This will prevent a new version of the bundle from installing "MyProduct" again. This will not prevent the bundle from installing it after you've already installed it from the MSI. To accomplish that, you can also have a RegistrySearch tag for a key created by your MSI.

philselmer
  • 751
  • 4
  • 22
-1

Add DisableRemove="yes" and DisableModify="yes" to Bundle and Visible="yes" for MSI. It couse show only MSI instance in Remove/Add programs.

<Bundle Name="InstallerBoot" Version="$(var.BuildVersion)" Manufacturer="Company" UpgradeCode="GUID" DisableRemove="yes" DisableModify="yes">
    ...
    <MsiPackage Id="MainPackage" SourceFile="..\Installer.msi" DisplayInternalUI="yes" Compressed="yes" Vital="no" Visible="yes">
</Bundle>

And change UpgradeCode in Bundle for each version.(In my program dont change upgradeCode was causing show additional bootstrapper windows after install msi)

Silny ToJa
  • 1,815
  • 1
  • 6
  • 20