Wix Burn, how do I allow downgrading?

Question

So I've got a pretty simple burn installer, primarily to include .net upgrades or occasionally a driver pack for hardware our app needs to talk to.

The MSI's we create support upgrading or downgrading.

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"       
     xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
    <Bundle Name="My App Name" Manufacturer="Company Name" Version="!(bind.packageVersion.MyAPP_MSI)"
            IconSourceFile="MyIcon.ico"  DisableModify="yes" DisableRemove="yes"
            UpgradeCode="{15E598EF-89CE-470B-8CEF-E32C8983DA33}" >
        <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" >
            <bal:WixStandardBootstrapperApplication
                LogoFile="$(var.CoreComponents.TargetDir)InstallerGraphics\Bootstrapper_Logo.png"
                LicenseFile="$(var.CoreComponents.TargetDir)AppRoot\App License.rtf" 
                SuppressOptionsUI="yes" />
        </BootstrapperApplicationRef>

        <Chain>
            <PackageGroupRef Id="NetFx451Web"/>

            <MsiPackage DisplayName="My full Application Name"  Id="MyAPP_MSI" SourceFile="$(var.Installer_MyAppMSI_TargetPath)"
                        DisplayInternalUI="yes" ForcePerMachine="yes" Visible="yes" />

        <MsiPackage DisplayName="My Hardware Driver" Id="Installer_MSI_Driver" SourceFile="$(var.Installer_Driver.TargetPath)"
                    DisplayInternalUI="yes" ForcePerMachine="yes" Visible="yes" />

        </Chain>
    </Bundle>
</Wix>

We typically have beta releases and when a user wants to downgrade from a beta back to our stable releases they can't simply execute the old EXE installer. They have to remove previous package from Add/Remove Programs explicitly to installer the older Burn EXE.

This wasn't an issue with the MSI based install. How do we get back to that functionality?

Log

[0CB8:067C][2014-06-23T11:10:04]i001: Burn v3.8.1128.0, Windows v6.1(Build 7601: Service Pack 1), path:\\iop-filesvr\IOP\Builds\Main\8.1.240\IO Practiceware Client Setup.exe, cmdline: '-burn.unelevated BurnPipe.{197B8193-6EFC-4ED0-AF90-DE7205F13E65} {CD23A8AB-520B-4F5D-BCB9-98998C5A1EC0} 2216'

[0CB8:067C][2014-06-23T11:10:04]i000: Setting string variable 'WixBundleLog' to value 'C:\Users\jeff\AppData\Local\Temp\IO_Practiceware_Client_8.1.240.0_20140623111004.log'

[0CB8:067C][2014-06-23T11:10:04]i000: Setting string variable'WixBundleOriginalSource' to value '\\iop-filesvr\IOP\Builds\Main\8.1.240\IO Practiceware ClientSetup.exe' 

[0CB8:067C][2014-06-23T11:10:04]i000: Setting string variable 'WixBundleName' to value 'IO Practiceware Client 8.1.240.0'

[0CB8:067C][2014-06-23T11:10:05]i100: Detect begin, 2 packages

[0CB8:067C][2014-06-23T11:10:05]i000: Setting string variable 'PrerequisitesVersion' to value '1.0.0.0'

[0CB8:067C][2014-06-23T11:10:05]i102: Detected related bundle: {8d398d25-606f-419a-9b29-e3434aeb2485}, type: Upgrade, scope: PerUser, version: 8.1.241.0, operation: Downgrade

[0CB8:067C][2014-06-23T11:10:05]i103: Detected related package: {7EA877FF-CE7A-49CE-8F76-D5A11EA7DD7A}, scope: PerMachine, version: 1.0.0.0, language: 0 operation: MajorUpgrade 

[0CB8:067C][2014-06-23T11:10:05]i103: Detected related package: {8E8A7689-FB1C-4FE5-AF7C-95D499A342DE}, scope: PerUser, version: 8.1.241.0, language: 0 operation: MajorUpgrade 

[0CB8:067C][2014-06-23T11:10:05]i101: Detected package: PrerequisitesMsi, state: Absent, cached: None

[0CB8:067C][2014-06-23T11:10:05]i101: Detected package: ClientMsi, state: Absent, cached: None 

[0CB8:067C][2014-06-23T11:10:05]i199:Detect complete, result: 0x0 

[0CB8:076C][2014-06-23T11:10:16]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 0

[0CB8:076C][2014-06-23T11:10:16]e000: Error 0x80070666: Cannot install a product when a newer version is installed.

Ditter

So what is happening when you run the old burn exe installer? Ideally burn handles upgrades at the burn level and the MSI level. So if the MSI is setup to do downgrades, it should happen. If it is not happening, can you please paste the burn install/uninstall logs? – Swagerty

You say "downgrade from a beta back to our stable release". We treat a stable release as being an upgrade from a beta release. e.g. Beta 1.2.3.1234 is seen by the user as "1.2.3.1234". The following release is 1.2.3.1235 but is seen by the user as, say, "1.2". The version number used by Wix can be different to the version seen by user user. e.g. informational version. – Subjection

Answer 1

Try to add <Property Id="REINSTALLMODE" Value="amus" /> in your product.wxs file. REINSTALLMODE property is a set of settings which defines the behavior of new installation with different/same version. For more details, you can check REINSTALLMODE property as reference.

Indefensible

Tried adding this property, but it still wouldn't let me downgrade the version. See my answer for something that worked for me. – Folksy

+1. Definitely looks a better solution. But this one worked for me as I enabled msi to rewrite of all registry and copy oll the files again by setting this property. Would try the solution provided by you. I'll add in comments if it works for me. – Indefensible

I had to combine this and Contango's answer to get it working. – Pelting

Answer 2

This worked for me:

<MajorUpgrade Schedule="afterInstallInitialize" AllowDowngrades="yes"  />

See WIX docs on MajorUpgrade Element.

Folksy

This will not work for a bundle, only for a product. (And the question is about a bundle) – Senzer

It worked for me, but it deletes all user files at upgrade. – Ornis

@Folksy where did you place this element under in the BootStrapper? – Wooten

@Wooten Try searchcode.com for examples of usage in context, e.g. search for "afterInstallInitialize", filter by WiX source. – Folksy

Answer 3

Treat betas as releases leading up to stable (RC or market) releases. The file/assembly version always moves up, so the install is an upgrade.

Take this sequence of releases:

• 1.2.3.4567 Beta
• 1.2.3.4568 Market release
• 1.2.4.4569 Next Beta

Define the version that the customer sees depending on if a market (stable) release or a beta.

Check out 'AssemblyInformationalVersion'.

[assembly: AssemblyVersion("1.0.0.1234")]
[assembly: AssemblyFileVersion("1.0.0.1234")]
[assembly: AssemblyInformationalVersion("1.0")]

Always upgrade.

Subjection

Yes and that's exactly how it works. The issue is, that when 1.2.4.4569 has a flaw and people want to rollback to 1.2.3.4568, they can't simply run the older installer. With msi's they could do that and it would work successfully. – Ditter

Roll back to a beta or roll back to prior market release? Rolling back to a beta should require uninstall / reinstall, bigger issues at play. Prior market release should increase major version number to allow for independent multiple version installs ... but that also requires your app to use separate app data folders etc. – Subjection

I don't think your idea of how software is deployed squares with mine. We release beta software every 3-4 weeks and an official release every 4-6 months. These aren't major revisions, it would be non-sensical to have them install side-by-side. They are in place upgrades. Rolling back from a new this week beta, to last months official release is possible via MSI, but not via burn. The MSI does an uninstall and then lays down the new version. It worked perfectly before we changed to burn. Burn does several other nice things, it just sucks that it doesn't handle this. – Ditter