WIX - How to selectively uninstall the <Bundle>

Question

I want to retain the previous versions of my Bootstrapper App, how to achieve this?

I know that we can use the Upgrade tag in MSI where we can identify the different versions and perform uninstall operations base on those.

Now, I have a Bundle Application that has one or more MSI which use some UpgradeCode. Each time I create a new build I just version up the MSI and this Bundle Application. When I proceed with installing of later version of Bundle App, it uninstall the previous Bundle version, which is not what I want. I want to retain the previous versions of my Bundle Application.

Is there anything like UpgradeVersion in Bundle as well, where we would be able to identify the diferent versions and do selectively uninstall.

My Bundle file code snippet :

    <Bundle Name="myApp"
          Version="1.0.0.0"
          Manufacturer="Myself"
          UpgradeCode="SOME-GUID">

          <BootstrapperApplicationRef Id="ManagedBootstrapperApplicationHost" >
          ...
          </BootstrapperApplicationRef>

    <Chain>
      <PackageGroupRef Id= 'WindowsInstaller45'/>
      <PackageGroupRef Id ='NetFx45Offline'/>
      <PackageGroupRef Id ='MY_MSI'/>
    </Chain>
</Bundle>

<Fragment  Id ='PkgFragments'>
<PackageGroup Id ="MY_MSI">
      <MsiPackage SourceFile= "$(var.Installer.TargetPath)"
                  Id="MYAPP"
                  Cache ="yes"
                  Visible ="no"
                  DisplayInternalUI ="no"
                  Permanent="no">
        <MsiProperty Name='INSTALLLOCATION' Value='[InstallFolder]' />
        <MsiProperty Name='SELECT_UNINST' Value='[UninstallPrevVersion]' />
      </MsiPackage>
</PackageGroup>
</Fragment>

My Product WIX file code snippet

<Product Id="*"
           Name="$(var.ProductName)"
           Version="$(var.ProductVersion)"
           Manufacturer="$(var.ManufacturerName)"
           UpgradeCode="$(var.UpgradeCode)">

    <Property Id="SELECT_UNINST" Secure="yes">1</Property>

    <Upgrade Id="SOME-GUID2">
      <UpgradeVersion Minimum="0.0.0.0" Maximum="$(var.ProductVersion)" IncludeMinimum="yes" IncludeMaximum="yes" Property="UNINSTALL_PREV_VERSION" />
    </Upgrade>

    <CustomAction Id="UninstPrev" Property="UNINSTALL_PREV_VERSION" Value="0" />

    <InstallExecuteSequence>
      <Custom Action="UninstPrev" Before="InstallInitialize"><![CDATA[SELECT_UNINST <> 1]]></Custom>
      <RemoveExistingProducts Overridable="no" After="UninstPrev"></RemoveExistingProducts>
    </InstallExecuteSequence>

</Product>

Answer 1

I'll put this as an answer too.

If you don't want to remove your previous versions don't treat the new version as an upgrade to the old one. This means change the upgrade GUID and change the product GUID. If you need to remove a specific version, add the bundle as a <RelatedBundle> in your Bundle definition and properly handle OnPlanRelatedBundle in your Bootstrapper Application.

<RelatedBundle Action="Detect" Id="$(var.ProductVersion622UpgradeGUID)"/>

Additionally, any msi packages you install also would need to employ the same behaviour of new upgrade GUIDs if you don't want removal between "upgrades". Keep a list of which GUIDs are with which released versions. If you want to remove specific versions in a release of your msi you need to add

<Upgrade Id="$(var.Version6InstallerUpgradeGUID)" >
    <UpgradeVersion
        IncludeMaximum ="no"
        IncludeMinimum="yes"
        Maximum="6.0.0.1"
        Minimum="6.0.0.0"
        MigrateFeatures="no"
        Property="V6FOUND"
        OnlyDetect="no" />      
</Upgrade>

I would consider this requirement very odd and would suggest you really think upon whether or not you really want to support this kind of behaviour.

Also to note, the entry in the ARP for the bootstrapper existing doesn't necessarily mean the products it installed are still on the system. You can test this by always setting pRequestedState = RequestState.Present; in OnPlanRelatedBundle and setting your msi packages to visible="yes". You will have the old bundle listed in the ARP but the packages it installs were probably upgraded by the newer version so it's just an entry that doesn't mean anything.