We have some product, that uses WIX as installer technology. Upgrade handling in the installer is handled by he MajorUpgrade element
<Wix>
<Product Id="..." Name="..." Language="..."
Version="..." Manufacturer="..."
UpgradeCode="...">
...
<MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeError)" AllowSameVersionUpgrades="yes" />
</Product>
</Wix>
As you can see, we supported upgrades from all older version until now, however we have to change this a bit, so that only versions newer than a certain version can be upgraded, while older versions receive an error message and upgrade fails.
From what I've researched, this should be doable with the Upgrade element (as described in https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/checking-for-oldies/)
My question now:
is it possible/recommended to mix MajorUpgrade and Upgrade elements?
is there a better way for achieving this?
Update
Thanks for the replies and answers, my used solution is the following:
<Wix>
<Product Id="..." Name="..." Language="..."
Version="..." Manufacturer="..."
UpgradeCode="My_upgrade_code">
...
<InstallExecuteSequence>
...
<Custom Action='UpdateFromVersionNotSupported' After='FindRelatedProducts'>UNSUPPORTEDUPDATEVERSIONFOUND</Custom>
...
</InstallExecuteSequence>
<MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeError)" AllowSameVersionUpgrades="yes" />
<Upgrade Id='My_upgrade_code'>
<UpgradeVersion OnlyDetect='yes' Property='UNSUPPORTEDUPDATEVERSIONFOUND' Maximum='Oldes_version_where_update_is_allowed' IncludeMaximum='no' />
</Upgrade>
<CustomAction Id='UpdateFromVersionNotSupported' Error='Updates are only supported from version ?? or later' />
</Product>
</Wix>
There should be a few approaches:
New UpgradeCode: Changing the upgrade code would decouple the older versions and the newer ones? You can add both upgrade codes to the upgrade table and handle them differently. See the image below and this answer:
Versioning: You can also use version matching to upgrade only certain MSI versions. Upgrade Table documentation. In other words set the max and min versions to target with each upgrade table entry. You can keep adding rows to handle different versions differently. Something like this (just a rough mock-up):
WiX Constructs: You can mix and match the modern WiX convencience element
with the older and more flexible elements. See this answer.
Side-By-Side MSI: Note that if you want to install the same MSI twice on the same computer interference will result unless you do work to isolate the instances (COM servers, file associations, services, etc... - anything machine-wide and interference capable). The worst of it is generally things registered system-wide accessed via the registry (unless it is multi-instance capable). More technical information here. Virtualization can help? See the links for details.
You'll need to use the Upgrade element.
https://wixtoolset.org/documentation/manual/v3/xsd/wix/upgrade.html
https://wixtoolset.org/documentation/manual/v3/xsd/wix/upgradeversion.html
You need to write 2 rules. One that allows an upgrade for version X or higher. This can be your standard MajorUpgrade element. And another that detects a version <X and triggers a Condition that displays a message informing the user to uninstall first and blocks installation.
Related
We have been using the MajorUpgrade element in wix 3.11.1.2318, and our installer is not upgrading properly. It is not removing files and is leaving an extra entry in add/remove programs. During our build we switch Version="0.0.0.0" with the current version.
Below is a reduced sample to show our usage:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" >
<Product Id="*" Name="My Product" Language="1033" Version="0.0.0.0" Manufacturer="MyCompany"
UpgradeCode="{B55B9CB0-BA28-4BB3-834B-6075AD5D45E4}">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<UIRef Id="WixUI_ErrorProgressText" />
<!-- Specify UI -->
<Property Id="WIXUI_INSTALLDIR" Value="INSTALL_FOLDER" />
<Property Id="RestoreFiles" Value="INSTALL_FOLDER" />
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" DowngradeErrorMessage="!(loc.NewerVersionInstalled)" />
</Wix>
I looked at the Upgrade table in our msi, one entry had the MinVersion set to the version we had built and with no max version.
Another entry had the MaxVersion set to the version we had just built, and with no min version.
I thought that with the MinVersion set to our current version we would not be able to remove the files, so I looked
at the Upgrade element and replaced the MajorUpgrade element.
<!--
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" DowngradeErrorMessage="!(loc.NewerVersionInstalled)" />
-->
<Upgrade Id="{B55B9CB0-BA28-4BB3-834B-6075AD5D45E4}">
<UpgradeVersion Minimum="1.0.0"
IncludeMinimum="yes"
OnlyDetect="no"
Maximum="0.0.0.0"
IncludeMaximum="no"
Property="OLDVERSIONFOUND" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
This did remove the older files, but left the second add/remove programs entry.
Is there a way with MajorUpgrade to set a minimum version?
Should I stay with Upgrade if there is no method to set minimum version?
What might be causing the second entry?
Logging: Please make sure to create a proper verbose log file for better clues to what is going on.
Major Upgrades: Some previous answers:
Here is a list of common causes of failed major upgrades (please skim the list first)
The use of both legacy and modern constructs to implement major upgrades.
Annotated WiX source showing old style major upgrades constructs in use
The upgrade settings you describe sound normal for WiX. I assume your build process successfully replaces the placeholder 0.0.0.0 (you search for that and replace it I presume). You could also use WiX variables and pass the value in, but that is another story.
Dangling Version?: Are you sure you don't have a dangling version in Add / Remove that isn't removed because it was a test version or something like that? Try generating a list of installed packages. Previous link is for a script which creates a small HTML report, you can try this simpler script to create output in *.csv format (which you can import to Excel and sort by name column to find duplicates easily). Try to install on a clean virtual to make sure. Just need to verify that this is not the case - one of those things that can be left unverified and be the cause.
Upgrade Table: Below is a sample upgrade table. Notice that the first entry is for the real major upgrade. It will detect all lower versions than the max version specified. You don't need to upgrade if your version is already installed. Hence we don't need max to be higher than the current version we install. In fact if the version you try to install you are supposed to go into "maintenance mode" - which shows a list of features you have installed and whatever features you have not installed.
The second row is to prevent overwriting a higher, existing installed version with a lower version than the setup you are running.
I've made an installer using the WIX toolset (3.10). I'd like to enable upgrades but I can't make it work. Every time I run the msi it installs another version.
I can't figure out what's wrong. can anyone advise?
<Product Id="*"
Name="$(var.PRODUCTNAME)"
Language="1033"
Version="$(var.PRODUCTVERSION)"
Manufacturer="Manufacturer"
UpgradeCode="UPGRADE_CODE"
>
<Package InstallerVersion="200"
Compressed="yes"
InstallScope="perMachine" />
<MajorUpgrade Schedule="afterInstallInitialize"
AllowDowngrades="no"
AllowSameVersionUpgrades="no"
DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes" />
AllowSameVersionUpgrades="yes" will probably fix this. When you test upgrades you need to either always update the version (one of the first 3 parts) between installers or just allow the same version upgrades.
from the wix website
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.
So your install thinks these two installs are separate things even though they share the same upgrade code which is why you get 2 copies in your add remove programs list.
I use a GUID for the UpgradeCode (I suppose that's what UPGRADE_CODE means).
You can also set the REINSTALLMODE property to change your reinstallation behavior.
It could look like this:
<SetProperty Id="REINSTALLMODE" Value="amus" After="FindRelatedProducts">Installed AND REMOVE<>"ALL"</SetProperty>
Just be aware that a will reinstall your product regardless of the installed version. But you can look up which characters you need for your installer.
For Value="amus" you can refer to the Microsoft documentation here
In addition to your MajorUpgrade property it is crucial that your UpgradeCode does not change for future versions. Might that be the problem?
My WiX installer does not uninstall previous version record in ARP when I change the version number. It installs the updated files, but I end up with duplicate records in ARP. Does this have something to do with minor versus major upgrades? The beginning of my WiX installer file is as follows:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="Blah" Language="1033" Version="1.0.0.6" Manufacturer="Blah Inc." UpgradeCode="c6044fe4-e07a-4dd0-9540-cc77b4430466">
<Package Id ="*" Keywords="Installer" Description="Blah Installer" Manufacturer="Blah Inc." InstallerVersion="200" Compressed="yes" InstallScope="perMachine" InstallPrivileges="elevated" />
<Property Id="OLDVERSION" Secure="yes" />
<Upgrade Id="7BDF86F7-C6A8-4112-9DA6-FDFB6864AE66">
<UpgradeVersion OnlyDetect="no" Minimum="1.0.0.0" Maximum="99.0.0.0" Property="OLDVERSION" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts Overridable="no" After="InstallInitialize" />
</InstallExecuteSequence>
Couple of things to check:
Is the Upgrade ID same for both MSI's? The MSI wont know that there is a related product installed unless the upgrade GUID's are same.
Looks like you have updated only the last digit of the version number? if your version 1 uses Version value 1.0.1.0, then version 2 should have a Version value of 1.0.2.0 or higher (1.0.1.1 will not work here).
From Wix3.5, there is a new element called MAJORUPGRADE MajorUpgrade which consolidates the lines which you have written and makes things easier. Can you make use of that and see if it works? Here is a link to Bob Arnsons blog introducing "MajorUpgrade" MajorUpgrade
Check this link for more details: How to implement major upgrade
Your Upgrade Code must generally be stable across versions to identify the products in question as related. They seem to differ in your code.
Furthermore you must implement a major upgrade to ensure that the old product version is uninstalled before the new one is installed. Otherwise you will get multiple installations showing up in ARP.
For good measure always uppercase your GUIDs, though I believe WIX will do this for you on compile. And make sure you uninstall all versions of your application before you try anything else.
I have a product that used to ship with a .vdproj installer. In the most recent version, I shipped a beta with a completely redone installer using WiX (as part of the move to Visual Studio 2012, which no longer supports .vdproj). Unfortunately, at the time I didn't know that the upgrade code was supposed to be consistent across copies, and already shipped one beta installer with a different upgrade code.
I would like my installer to automatically remove previous versions built with the .vdproj installer, as well as the version that was shipped as a beta copy. This is where I've gotten so far:
<Product Id="{A4CBA9F9-D86B-400C-BD23-996B4367931A}" Name="Foo Viewer" Language="1033" Version="6.0.1.0" Manufacturer="Foo Corporation" UpgradeCode="43e024b8-b3ea-40a3-a854-2af83f207f0f">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MediaTemplate EmbedCab="yes" />
<Feature Id="FOOVIEWERFeature" Title="Foo Viewer" Level="1" Description="The Foo Viewer GUI and CLI binaries." AllowAdvertise="no" Absent="disallow" Display="expand">
<!-- Stuff -->
</Feature>
<PropertyRef Id="NETFRAMEWORK40CLIENT" />
<Condition Message="Foo Viewer requires the .NET Framework 4.0 Client Profile or higher to run.">Installed OR NETFRAMEWORK40CLIENT</Condition>
<Property Id="WIXUI_INSTALLDIR" Value="INSTALLFOLDER" />
<UIRef Id="FooViewerInstallerUI" />
<UIRef Id="WixUI_ErrorProgressText" />
<Icon Id="FooViewerIcon" SourceFile="../FooViewer.ico" />
<Property Id="ARPPRODUCTICON" Value="FooViewerIcon" />
<!-- I got this upgrade code by opening one of the old .vdproj MSIs in Orca -->
<Upgrade Id="{80539F30-8176-4DCC-A102-ED32A34A91CB}">
<UpgradeVersion OnlyDetect="no"
Minimum="0.0.0.0"
IncludeMinimum="yes"
MigrateFeatures="no"
IgnoreRemoveFailure="no"
Property="UPGRADE_VDPROJ_FOOVIEWER"
/>
</Upgrade>
<Upgrade Id="{43e024b8-b3ea-40a3-a854-2af83f207f0f}">
<!-- Foo Viewer 6.0.0.0 (Beta) shipped with a version 5.3.0.0 in the installer. -->
<UpgradeVersion OnlyDetect="no"
Minimum="5.3.0.0"
Maximum="5.3.0.0"
IncludeMinimum="yes"
IncludeMaximum="yes"
MigrateFeatures="yes"
IgnoreRemoveFailure="no"
Property="UPGRADE_WIX_FOOVIEWER"
/>
<!-- Detect newer versions -->
<UpgradeVersion OnlyDetect="yes"
Minimum="6.0.1.0"
IncludeMinimum="no"
Property="NEW_VERSION_FOUND"/>
</Upgrade>
<Condition Message="A newer version of Foo Corporation Foo Viewer is already installed.">
Installed OR NOT NEW_VERSION_FOUND
</Condition>
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
</InstallExecuteSequence>
</Product>
However, despite putting in a <upgrade> element for the old installer's upgrade code, the old version isn't getting removed. As a result the new copy tries to install on top of the old copy, and then neither version works any longer.
The detection of the beta copy, and of newer versions, works correctly (the <Upgrade with GUID {43e024b8-b3ea-40a3-a854-2af83f207f0f} ). The beta version gets uninstalled, and if I generate a "newer" installer, then the current installer correctly doesn't install. That is, the WiX installers have no problem detecting each other.
Is there something I did wrong here that won't let it detect the old .vdproj installed copies?
EDIT: I tool a log of the installation process when this happens, I get the following:
Action start 17:25:47: FindRelatedProducts.
MSI (c) (10:B8) [17:25:47:269]: FindRelatedProducts: current install is per-machine. Related install for product '{2024FF03-D6F2-4065-A22B-80252B2A66B6}' is per-user. Skipping...
Action ended 17:25:47: FindRelatedProducts. Return value 1.
which appears to be accurate. The old installer gave an option for "Per User" or "Per Machine", whereas the new installer always forces per machine. If I select "Everyone who uses this computer" in the old installer, then the new installer is able to detect it. I would like to detect either option if possible in the WiX.
I'm afraid you can't deal with 2 different existing installations at the same time in single installer. Moreover you shouldn't try to run uninstallation of another product (since your UpgradeCode and ProductCode are different, it is anoter product) because msi can't work with simultaneous installations.
What I would recommend is creating separate exe application (bootstrapper), which will run child uninstallation processes of previously installed products and then immediately run your product's installation (probably in full UI mode).
To uninstall the product with no user interaction, use the following command:
msiexec /x {ProductCode} /qn
I hope you know the ProductIds of the previously installed products. If not, you can find it, searching the registry:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}\DisplayName
and HKEY_CURRENT_USER if application was installed for single user.
{ProductCode} mentioined in registry path is GUID which is your productCode. You should retrieve all nodes in "Uninstall" branch and find those which are your products checking the "DisplayName" attribute. I hope you know at least the name of the products installed =). And be careful not to delete all software on client's machine =)
Please note if you installed x86 application on x64 machine, you should search location
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}\DisplayName"
One more important notice: if your bootstrapper will be also x86 application, you should retrieve node without "Wow6432Node" node because it will be automatically inserted in the requested path. Wonderful world of registry keys on different platforms =).
Please ensure your bootstrapper will be run with admin permission or will ask permission elevation (it should contain security manifest).
One assumption about problem in your post: maybe you didn't change the ProductCode when changed the UpgradeCode? I'm not sure how it will behave, but it is definitely not a MajorUpgrade which automatically removes the previously installed product. For more details see Wix documentation on upgrades. So you might got Minor upgrade or patch which directly installs new components on top of the previously installed files. That definitely could break the application.
We use wix to create our setups. For upgrading, we use major upgrades as demonstrated in this answer by Rob Mensching. (In newer wix versions you can use the MajorUpgrade element.) This normally works well. The old product is removed, then the new product is installed.
However, apparently the above is not completely equivalent to manually uninstalling the old product and then manually installing the new product.
Consider for example the following scenario:
version 1.0 of our product is released, containing version 5.0 of a thirdparty dll
version 1.1 of our product is released, containing version 5.1 of the same thirdparty dll
version 1.2 of our product is released, downgrading to version 5.0 of the thirdparty dll again because we discovered that the new version introduced more problems than it solved.
Apparently with the wix upgrade logic linked above, the 3rdparty dll will disappear when upgrading from release 1.1 to 1.2. A repair is necessary to restore it.
Is there another way to upgrade, which would work for this scenario? I guess what I am looking for is upgrade logic which allows the downgrading of components, by behaving exactly as if one manually uninstalls the old product and then manually installs the new product.
We also encountered this problem where lower-versioned DLLs were not getting reinstalled on a major upgrade. I thought it was strange that the installer would decide which files to install based on the versioning of existing files, then completely uninstall everything, but still only install what what files had been determined to install before uninstalling the old product. This seems like it might be a bug in Windows Installer...
To fix this problem we moved the RemoveExistingProducts action above the CostFinalize action.
I know the documentation on MSDN recommends placing the RemoveExistingProducts afterInstallValidate, and I'm not sure if putting it before the InstallValidate action has any negative side effects for minor upgrades, but we have decided to only perform major upgrades for our products so this solution appears to work for us.
Behaviors like this generally have to do with the sequencing of RemoveExistingProducts. If it occurs late enough, Windows Installer will have figured out that there's a newer version of the .dll on the machine, so version 1.2 doesn't need to install it. However when the RemoveExistingProducts results in removing the .dll, nothing puts it back.
Things to try including changing the sequencing of RemoveExistingProducts, and lying about the version of the .dll in your 1.2 package (report a version number higher than the bad one). The downside of the latter is poor impacts on repairs or patching, as the .dll always looks out of date.
Try to schedule RemoveExistingProducts earlier, right after InstallValidate, and change the value of REINSTALLMODE property to amus. This way the old product will be completely removed before any files from the new product are copied, and a mode will force re-install of the files.
It's sub-optimal, but I fixed the same problem by renaming the third party dll and changing the GUID on the component node associated with it in the .wxs file.
Years later, this thread helped me in the right direction. An example for completeness with RemoveExisitingProducts moved before costing:
<Upgrade Id="UPGRADE-GUID-HERE">
<UpgradeVersion OnlyDetect="no" Property="UPGRADABLEFOUND"
Maximum="$(var.ProductVersion)" IncludeMaximum="yes" />
<UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND"
Minimum="$(var.ProductVersion)" IncludeMinimum="no" />
</Upgrade>
<InstallExecuteSequence>
<Custom Action="NoDowngrade" After="FindRelatedProducts">NEWERFOUND</Custom>
<RemoveExistingProducts Before="CostInitialize" />
</InstallExecuteSequence>
<CustomAction Id="NoDowngrade" Error="A newer version of $(var.ProductName) is already installed." />
Here's my final solution based on the answer given by #Spacemani.
It produces MSI table entries (Upgrade, LaunchCondition etc.) similar to this
<MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeErrorMessage)" />
but gives you full control of the InstallExecuteSequence.
<!-- Product upgrade -->
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion OnlyDetect="no" Property="WIX_UPGRADE_DETECTED"
Maximum="$(var.ProductVersion)" IncludeMaximum="no" IncludeMinimum="no"
MigrateFeatures="yes" />
<UpgradeVersion OnlyDetect="yes" Property="WIX_DOWNGRADE_DETECTED"
Minimum="$(var.ProductVersion)" IncludeMinimum="no" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts Before="CostInitialize" />
</InstallExecuteSequence>
<Condition Message="!(loc.DowngradeErrorMessage)">NOT WIX_DOWNGRADE_DETECTED</Condition>
Note that you need to suppress ICE27 errors in your .wixproj file like this.
<PropertyGroup>
<SuppressIces>ICE27</SuppressIces>
</PropertyGroup>