9

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.
prakash
  • 1,413
  • 1
  • 21
  • 33
Joel Barsotti
  • 3,031
  • 7
  • 35
  • 59
  • 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? – Isaiah4110 Jun 22 '14 at 03:58
  • 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. – Rob Smyth Jan 07 '15 at 06:25

3 Answers3

3

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.

DTdev
  • 538
  • 1
  • 18
  • 32
  • 1
    Tried adding this property, but it still wouldn't let me downgrade the version. See my answer for something that worked for me. – Contango Jun 08 '17 at 09:05
  • +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. – DTdev Jun 08 '17 at 13:30
  • 1
    I had to combine this and Contango's answer to get it working. – Randy Burden Mar 16 '21 at 17:10
3

This worked for me:

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

See WIX docs on MajorUpgrade Element.

Contango
  • 76,540
  • 58
  • 260
  • 305
0

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.

Rob Smyth
  • 1,768
  • 11
  • 19
  • 1
    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. – Joel Barsotti Jan 07 '15 at 14:46
  • 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. – Rob Smyth Jan 07 '15 at 22:43
  • 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. – Joel Barsotti Jan 08 '15 at 02:34