msi upgrade when I change the ProductVersion to a different format fails - wix

I have the following problem and I'm trying to understand what is happening. I have this code:
...
<Product Name="My Service"
Id="*"
UpgradeCode="$(var.UpgradeCode)"
Language="$(var.Language)"
Codepage="$(var.CodePage)"
Version="$(var.ProductVersion)"
Manufacturer="$(var.Manufacturer)">
<Package Id="*"
Keywords="Installer"
Description="My Service Installer"
Comments="Service Installer"
Manufacturer="$(var.Manufacturer)"
InstallerVersion="300"
Languages="$(var.Language)"
Compressed="yes"
SummaryCodepage="$(var.CodePage)" />
<Upgrade Id="$(var.UpgradeCode)">
<!-- Populate NEWERVERSIONDETECTED if there is an installed
package with the same upgrade code
and version is > the version being installed -->
<UpgradeVersion Minimum="$(var.ProductVersion)"
IncludeMinimum="no"
OnlyDetect="no"
Property="NEWERVERSIONDETECTED" />
<!-- 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.ProductVersion)"
IncludeMaximum="no"
Property="PREVIOUSVERSIONSINSTALLED" />
</Upgrade>
<Condition Message="A newer version is already installed.">NOT NEWERVERSIONDETECTED</Condition>
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallInitialize" />
</InstallExecuteSequence>
<!-- Step 1: Define the directory structure -->
...
<!-- Step 2: Add files to your installer package -->
...
<!-- Step 3: Tell WiX to install the files -->
...
ProductVersion and FirstVersion has the x.x.x format. Because the msi contains only 3 files I prefer to uninstall everything and put the new files in place (like a major upgrade).
Here is what it's happening:
FirstVersion is defined as "0.0.1"; I build twice my project (to generate two msi with ProductVersion "0.0.2" for the first build and with "0.0.3" for the second). When I install 0.0.3 on top of 0.0.2 everything is going smoothly. In Add/Remove Programs I see the new version installed, "My Service" is up&running in Local Services, in Program Files I see my folder containing the new files.
If I build the project with the ProductVersion 2.0.2 and 2.0.3 (same steps as the previous ones), when I install 2.0.3 on top of 2.0.2, no error pops-up, the installation finishes successfully (at least Event Viewer says so) but my folder in Program Files doesn't exist, My Service is unknown in Local Services (it will not start). The only thing looking good is in Add/Remove programs which shows me the new version 2.0.3 is installed. And another strange thing is the fact that I can uninstall my application from Add/Remove Programs successfully. No error!
So why for 0.0.x format as ProductVersion upgrading is working fine, but
not for 2.0.x?
I tried to log the output of msiexec during the upgrading, but it is too
complicated for me.
PS: do not recommend another way of implementing upgrade. I need to stick
to this code because I'm using msitools which has a lot of limitations.

The versions is right, you haven't made any mistake there.
Without a verbose log your chances to find the problem are quite small. It is not hard at all. Follow the link above and you will find examples on multiple methods to generate a log and share it with us or try to read it be yourself.

Related

With Wix Toolset is there a way with MajorUpgrade to set a minimum version

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.

WIX: upgrade without removing old version

I have installed version 2.4.0. And I have an major update:
<?define Version="2.4.1.0"?>
<Product Id="*" Name="SuperProduct" Language="1033" Version="$(var.Version)" Manufacturer="MyCompany" UpgradeCode="$(var.UpgradeCode)">
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Minimum="1.0.0.0" Maximum="3.0.0.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" IgnoreRemoveFailure="yes" />
</Upgrade>
<MajorUpgrade AllowDowngrades="no" DowngradeErrorMessage="Cannot downgrade!" IgnoreRemoveFailure="yes" AllowSameVersionUpgrades="no" />
The major update should replace few dll files in my product (it contains only theese files). But the installer removes old version and installs new one. All old files except new files are removed. How can I install upgrade without removing old files (suppress RemoveExistingProducts). This is not an option to remove MajorUpgrade tag and receive 2 programs in Program Files (SuperProduct 2.4.0 and SuperProduct 2.4.1)
Do you have any ideas?
Make a patch instead of an upgrade. This is exactly what patches are for, replacing a few key files and leaving the rest of the install as-is. I haven't made a patch install yet but the steps should be in the wix tutorial or in Nick Ramirez's Wix 3.6 book. A minor upgrade may also work, I'm not 100% sure about the differences between the upgrade types as I always just implement a major upgrade

WiX: Patching a patch no longer works after upgrading from WiX 3.0 to WiX 3.6-8

I have a set of WiX scripts that used to allow me to create patches for patches, e.g. I would have full installers for the following version numbers:
11.00.38.01
11.00.38.02
11.00.38.03
I would then create patches between these numbers, i.e.
11.00.38.01-11.00.38.02
11.00.38.02-11.00.38.03
Using these scripts with WiX 3.0 I would be able to run
11.00.38.01
and then apply the
11.00.38.01-11.00.38.02 and 11.00.38.02-11.00.38.03 patches,
which would bring the installation up to
11.00.38.03
After upgrading to WiX 3.6 and later 3.7 and 3.8, this no longer works.
I can install one build and apply one patch to that build but I cannot install a build, patch the installation, and then apply another patch.
If I attempt to do that, I get the following error:
The upgrade patch cannot be installed by the Windows Installer service
because the program to be upgraded may be missing, or the upgrade
patch may update a different version of the program. Verify that the
program to be upgraded exists on your computer and that you have the
correct upgrade patch.
My patch template looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Patch
AllowRemoval="no"
Manufacturer="Acme"
MoreInfoURL="http://www.acme.com/"
DisplayName="$(var.ProductName) $(var.ProductVersion) Upgrade"
Description="Minor Upgrade"
Classification="Update"
>
<Media Id="5000" Cabinet="RTM.cab">
<PatchBaseline Id="RTM"/>
</Media>
<PatchFamilyRef Id="$(var.ProductShortName)UpgradeFamily"/>
</Patch>
<Fragment>
<PatchFamily Id='$(var.ProductShortName)UpgradeFamily' Version='1.0.0.0' Supersede='yes'>
<ComponentGroupRef Id='PatchComponents' />
</PatchFamily>
</Fragment>
</Wix>
Part of the .wxs script for the product looks like this:
<Product Name='Acme Server'
Id='6DE00366-36D8-4BA0-B911-8FBD7490C472'
UpgradeCode='0FDE99AC-D910-46CF-814D-D851B81D3816'
Language='1033'
Codepage='1252'
Version='$(var.ProductVersion)'
Manufacturer='Acme'>
<Package
Id='*'
Keywords='Installer'
Description="Acme Server"
Comments='Acme Server is a registered trademark of Acme.'
Manufacturer='Acme'
InstallerVersion='200'
Languages='0'
Compressed='yes'
SummaryCodepage='1252'
Platform='x86'
/>
<Upgrade Id='0FDE99AC-D910-46CF-814D-D851B81D3816'>
<UpgradeVersion OnlyDetect='yes' Property='SELFFOUND'
Minimum='$(var.ProductVersion)' IncludeMinimum='yes' Maximum='$(var.ProductVersion)' IncludeMaximum='yes' />
<UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
Minimum='$(var.ProductVersion)' IncludeMinimum='no' />
</Upgrade>
</Product>
The interesting thing is that the WiX 3.0 patch log contains the following line:
PATCH SEQUENCER: verifying the applicability of minor upgrade patch
c:\Install\10.10.11.01-10.10.11.02\AcmeServer.msp against product
code: {6DE00366-36D8-4BA0-B911-8FBD7490C472}, product version:
10.10.1101, product language 1033 and upgrade code: {0FDE99AC-D910-46CF-814D-D851B81D3816}
whereas the WiX 3.6+ patch log contains this line:
PATCH SEQUENCER: verifying the applicability of QFE patch
c:\11.00.38.01-11.00.38.02\AcmeServer.msp against product code:
{6DE00366-36D8-4BA0-B911-8FBD7490C472}, product version: 11.00.3801,
product language 1033 and upgrade code:
{0FDE99AC-D910-46CF-814D-D851B81D3816}
Notice that the 3.0 log says "minor upgrade patch" whereas the 3.6+ log says "QFE patch". I do not know if this is relevant here.
What could I be doing wrong here? Why did the behavior of the generated patches change? Of course, there have been minor tweaks to the WiX scripts over the past couple of years but as far as I know none of them were related to the patching process. It seems as if the main change was due to the switch from WiX 3.0 to a newer version.
EDIT:
I have verified that this change happened exactly at the time I switched from WiX 3.0 to WiX 3.6.
I have also noticed that if I apply the WiX 3.0-generated patches, the version number is updated in Programs & Features when a patch is applied to a full installation or another patch whereas with the WiX 3.6+-generated patches, the version number stays the same when a patch is applied to a full installation.
I am wondering if any defaults have changed for the command-line tools (torch, pyro, etc)?
The solution was to add a ProductVersion property reference to the PatchFamily element as seen in the snippet below:
<Fragment>
<PatchFamily Id='$(var.ProductShortName)UpgradeFamily' Version='1.0.0.0' Supersede='yes'>
<PropertyRef Id="ProductVersion"/>
<ComponentGroupRef Id='PatchComponents' />
</PatchFamily>
</Fragment>
That was all there was to it.
I do not see this mentioned in any of the documentation or the usual, old sample patch script found on the web, though now that I know what to look for, it is easy enough to find discussions about it.
As I mentioned in my original question, this element was not necessary when using WiX 3.0 which might go some way to explain its absence from the old patch sample.

Dealing with Changed Upgrade Code in WiX, where old installer allowed both per-user and per-machine

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.

Unable to update wise installer package with wix installer

I have a msi setup file which was created with wise for windows installer. Now I want to create a new version of this installer with Wix toolset. The problem is, that the installer detects the previous installed (wise created) version, but isn't able to upgrade it. I get the following error message:
"Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel"
I set the same upgrade code in both installers and chacnged the product code and the package code in the wix project. I set the upgrade informations as follows:
<!-- Upgrade information -->
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion Property="NEWPRODUCTFOUND"
IncludeMinimum="no"
Minimum="$(var.ProductVersion)"
OnlyDetect="yes"/>
<UpgradeVersion Property="OLDPRODUCTFOUND"
IncludeMinimum="yes"
Minimum="0.5.0"
IncludeMaximum="no"
Maximum="$(var.ProductVersion)"/>
<UpgradeVersion Property="NEWERVERSIONINSTALLED"
IncludeMinimum="yes"
Minimum="$(var.ProductVersion)"
OnlyDetect="yes" />
</Upgrade>
I also tried to ensure that the product will be installed for all users by setting the InstallScope to "perMachine"
<Package InstallerVersion="200"
InstallScope="perMachine"
Compressed="yes" />
I have other installer projects where all versions were created with wix and for them the upgrade works fine.
Make sure you increase the Product Version. Only newer product version can automatically upgrade the original package.
Also, please note that Windows Installer ignores the fourth version field (in case you are using it).