Does anyone know:
How can I Force wix installer to uninstall any previous copy previously installed, whether minor or major before installing a new version of our setup.
If 1) can't be done when running a new minor/major setup, can I at least display a message saying that a previous version was detected and it should first be uninstalled and cancel the setup?
Thanks.
UPDATE:
I've added the following to my settings.wxi
<Upgrade Id="$(var.UpgradeCode)">
<!-- Populate NEWERPRODUCTFOUND if there is an installed
package with the same upgrade code
and version is > the version being installed -->
<UpgradeVersion
Minimum="$(var.CurrentVersion)"
IncludeMinimum="no"
OnlyDetect="yes"
Language="1033"
Property="NEWERPRODUCTFOUND" />
<!-- Populate UPGRADEFOUND if there is an installed
package with the same upgrade code
and the version is between the earliest version defined
and the version being installed -->
<UpgradeVersion
Minimum="$(var.FirstVersion)"
IncludeMinimum="yes"
Maximum="$(var.CurrentVersion)"
IncludeMaximum="no"
Language="1033"
Property="PREVIOUSVERSIONSINSTALLED" />
</Upgrade>
I've defined the following in MyProduct.wxs
<?define CurrentVersion="5.0.0.18"?>
<?define FirstVersion="1.0.0.0"?>
<?define UpgradeCode="c1b1bfa0-9937-49eb-812c-5bac06eff858"?>
and finally, I've added this to my <InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
But it still not removing the old version when I increase my version to 5.0.0.19.
Maybe I'm looking at this the wrong way, but in my "Add/Remove Programs" window, I see my setup listed as 5.0.0.18 and I see a second entry as 5.0.0.19
Should I be changing the upgrade code every time I change my version? I thought I had read that this should never be changed.
Any ideas?
Thanks.
Setup tab > Run after execution input: your msi file name. Advanced tab > Mark Request Administrative access option checkbox.
Windows Installer XML Toolset (WiX, pronounced "wicks"), is a free software toolset that builds Windows Installer packages from XML. It consists of a command-line environment that developers may integrate into their build processes to build MSI and MSM packages.
Download. You can download the WiX toolset for free.
I figured out the answer after a lot of googling!! Windows Installer doesn't take into account the 4 number of the version which is what I was using i.e. 5.0.0.18.
It only looks at the first 3 sets of number making the version number. Once I changed my version to 5.0.18.0 to 5.0.19.0, it worked immediately with the code posted in the question and it removed the previous version and installed the newer one over it.
Note that I've actually removed the above code and ended up using the MajorUpgrade instead as it was all I needed:
<MajorUpgrade
AllowDowngrades="no"
AllowSameVersionUpgrades="no"
IgnoreRemoveFailure="no"
DowngradeErrorMessage="loc.NewerVersionInstalled"
Schedule="afterInstallInitialize"/>
Hope this helps someone else!
Here is the documentation for the AllowSameVersionUpgrades
attribute of the MajorUpgrade
element. It contains pertinent information. The emphasis is mine.
When set to no (the default), installing a product with the same version and upgrade code (but different product code) is allowed and treated by MSI as two products. When set to yes, WiX sets the
msidbUpgradeAttributesVersionMaxInclusive
attribute, which tells MSI to treat a product with the same version as a major upgrade.This is useful when two product versions differ only in the fourth version field. MSI specifically ignores that field when comparing product versions, so two products that differ only in the fourth version field are the same product and need this attribute set to yes to be detected.
Note that because MSI ignores the fourth product version field, setting this attribute to yes also allows downgrades when the first three product version fields are identical. For example, product version 1.0.0.1 will "upgrade" 1.0.0.2998 because they're seen as the same version (1.0.0). That could reintroduce serious bugs so the safest choice is to change the first three version fields and omit this attribute to get the default of no.
This attribute cannot be "yes" when
AllowDowngrades
is also "yes" --AllowDowngrades
already allows two products with the same version number to upgrade each other.
Setting this attribute to yes
is probably not what you want, though, because, according to the third paragraph, version 5.0.0.18 would be seen as an upgrade over version 5.0.0.19. Set this attribute to no
and use the third product version field to only allow upgrades.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With