I am creating a WIX installer for our software and now I have some issue when upgrading from previous Windows Installer packaged SW.
One thing before the problem, the upgrade from one WIX packaged SW to another WIX packaged SW is actually working fine, I am able to uninstall the older version and install the newer version. The real problem happens when the older version is Windows Installer packaged (which is our current solution) and the newer version is WIX packaged. Basically my WIX installer is unable to find out that a older version is already installed, so the newer version will be installed without uninstalling the old version.
How I make the connection between WIX installer and Windows installer: I set the UpgradeCode of WIX as the same as Windows installer one. I also check some examples online, and they suggest my current solution should work. Here is part of my .wxs file of the upgrade part:
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion OnlyDetect="yes" Minimum="$(var.VersionNumber)" Property="NEWPRODUCTFOUND" IncludeMinimum="no" />
<UpgradeVersion OnlyDetect="no" Maximum="$(var.VersionNumber)" Property="UPGRADEFOUND" IncludeMaximum="no" />
</Upgrade>
<CustomAction Id="PreventDowngrading" Error="A software with newer version number is found on this machine" />
<InstallUISequence>
<Custom Action="PreventDowngrading"
After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
</InstallUISequence>
<InstallExecuteSequence>
<Custom Action="PreventDowngrading"
After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
<RemoveExistingProducts After="InstallFinalize" />
</InstallExecuteSequence>
One thing might be worth mentioning is our SW is actually a Windows Service, I am not sure whether that matters. Thanks for any help!
Having the same upgradecode is not enough. You must also check that the two packages have the same install type, i.e. they both get installed per-user or per-machine. If the install type is different Windows Installer will skip the removal of the old version.
Related
I have a strange issue whereby WiX Installer appears to be detecting a SELFFOUND instead of a PREVIOUSFOUND.
I am moving an old InstallAware project over to WiX so I have copied the UpgradeCode from the project to this Product.wxs
<Upgrade Id='MyGuid'>
<UpgradeVersion OnlyDetect='yes' Property='SELFFOUND' Minimum='!(bind.FileVersion.MainEXE)' IncludeMinimum='yes' Maximum='!(bind.FileVersion.MainEXE)' IncludeMaximum='yes' />
<UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND' Minimum='!(bind.FileVersion.MainEXE)' IncludeMinimum='no' />
<UpgradeVersion Minimum="1.0.0"
IncludeMinimum="yes"
OnlyDetect="no"
Maximum="!(bind.FileVersion.MainEXE)"
IncludeMaximum="no"
Property="PREVIOUSFOUND" />
</Upgrade>
<CustomAction Id='AlreadyUpdated' Error='[ProductName] is already installed.' />
<CustomAction Id='NoDowngrade' Error='A later version of [ProductName] is already installed.' />
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize"/>
<Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
<Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>
</InstallExecuteSequence>
and the Upgrade GUID matches that in my Product tag of the UpgradeCode attribute. The product codes between the two versions is different but I don't think making these the same is a good idea.
The version installed by the old InstallAware project is 4.11.7311.0 and is visible in control panel with this version. The version I am trying to install via the Upgrade and remove the old version is 4.11.7314.0.
For some reason whenever I try to run the new WiX .msi it is throwing the [ProductName] is already installed message.
Am I missing something? Because everything seems correct to me. Thanks in advance. Wix Toolset v3.11.
Okay, so I found the problem, well there were multiple actually.
Firstly I ran the installer via command prompt to generate a log file.
msiexec /i "C:\Path\To\Installer.msi" /L*V "C:\ProgramData\Install.log"
I then searched this file for
FindRelatedProducts
and it found an application which was setting the SELFFOUND property, now I searched through the registry for the GUID and realised it was an old one from my testing, so I uninstalled this using
msiexec /x {FoundGuid}
Still having the issue at this point though, so repeated the process and found a message that said
FindRelatedProducts: current install is per-machine. Related install for product '{MyGUID}' is per-user. Skipping...
so all I had to do was change my InstallScope from perMachine to perUser and it detects correctly.
How can I make the install require a previous version to be installed?
Is that not the purpose of Upgrade element? I cannot get it to work as expected.
The upgrade is happy to launch with or without previous 1.2.3 version installed.
Here is what I did:
Opened version 1.2.3 of the original MSI in Wix Edit
Replaced a single DLL with an updated DLL
Updated version to 1.2.4
Updated Product Id
UpgradeCode did * not * changed
Added Upgrade element after the last Property element
Code Sample:
<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="{59BF7F9E-FF46-45D5-8050-F1477466A661}">
<UpgradeVersion Minimum="1.2.3" Maximum="1.2.3" IncludeMinimum="yes"
IncludeMaximum="yes" Property="PREVIOUSVERSIONSINSTALLED" />
</Upgrade>
<RemoveExistingProducts Sequence="1525" />
Thanks in advance,
-Ed
I have never heard of such a design. Normally you make a setup capable of installing fresh and to update any previous versions on the system. See this thread: How to implement WiX installer upgrade?
I am creating my installer msi using WIX.
My older application is already installed on machine when I am installing newer version of the application then it removes all files and assembly of older version and put newer version files and assembly but in programs and features of control panel shows both older and newer version.
I am using following code for upgrade
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)" IncludeMinimum="no" OnlyDetect="yes" Language="!(loc.lcid)" Property="NEWPRODUCTFOUND"/>
<UpgradeVersion Minimum="1.0.0.0" IncludeMinimum="yes" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Language="!(loc.lcid)" Property="UPGRADEFOUND"/>
</Upgrade>
<CustomAction Id="PreventDowngrading" Error="!(loc.CustomAction_PreventDowngrading)"/>
<InstallUISequence>
<Custom Action="SetWindowsTypeProp" Before="FindRelatedProducts">1</Custom>
<!--Custom Action="SetPresenceProperties" After="SetWindowsTypeProp">1</Custom-->
<Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
</InstallUISequence>
<InstallExecuteSequence>
<Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
<RemoveExistingProducts Before="InstallInitialize"/>
</InstallExecuteSequence>
Please help me how to remove entry from programs and features
This means your MajorUpgrade isn't working. FindRelatedProducts isn't finding the older version and therefore REmoveExistingProducts isn't working. For recent versions of WiX you can remove a lot of this code and replace it with the newer MajorUpgrade element. It's a higher level abstraction that simplifies much of this authoring.
In order to have a successful MajorUpgrade several things have to happen:
1) Old and New MSI have to have the same UpgradeCode GUID. (Although it's technically possible for an MSI to remove unrelated Products by using additional UpgradeCode properties we'll ignore this for the purpose of this question.)
2) Old and New MSI must have unique ProductCode GUIDs.
3) New MSI must have a higher version ProductVersion property. Please note that only the first 3 numbers are evaluated. ( 1.2.3 -> 1.2.4 works 1.2.3.4 -> 1.2.3.5 does not )
4) Old MSI and New MSI must be installed in the same context ( Per User->Per User or Per Machine -> Per Machine )
5) Upgrade Table must be authored correctly. Use the MajorUpgrade element to assist in this.
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>