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).
Related
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.
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
I implemented upgrade handlers and downgrade prevention
<Upgrade Id="$(var.UpgradeCode)">
<UpgradeVersion OnlyDetect="no" Minimum="$(var.MinimumUpgradeVersion)" Maximum="$(var.ProductVersion)" IncludeMinimum="yes" IncludeMaximum="no" Property="PREVIOUSVERSIONINSTALLED" MigrateFeatures="yes" />
<UpgradeVersion OnlyDetect="yes" Minimum="$(var.ProductVersion)" IncludeMinimum="no" Property="NEWERVERSIONINSTALLED" />
</Upgrade>
And further on
<Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWERVERSIONINSTALLED AND NOT Installed</Custom>
<RemoveExistingProducts After="InstallInitialize">PREVIOUSVERSIONINSTALLED</RemoveExistingProducts>
However, now when I try to double-click my MSI to do a repair the UI doesn't appear anymore. I am using the same Upgrade Code so Wix should automatically allow me to repair.
Any ideas?
To do a major upgrade it might be better to use the majorupgrade element to make sure that you've included everything required. That's assuming you want a major upgrade, and I can't tell.
You are misunderstanding something. You (in WiX) use the majorupgrade element when you have a new version of your product that will replace the older one, and that includes a new ProductCode and the same UpgradeCode. This is nothing to do with repair. A repair is one of the options that can be available when you try to modify the existing installed product as defined by ProductCode, not UpgradeCode. A repair is not an upgrade or any kind of update. It repairs the existing product and will require the same MSI file that the product was originally installed from. The same UpgradeCode is nothing to do with repair.
What GUI are you including? See an online tutorial here: http://wix.tramontana.co.hu/tutorial/user-interface/ui-wizardry
Are you setting the ARPNOREPAIR property? Check in the registry at the following location (subkey, check for DWORD NoRepair):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
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.
I have installed major upgrade (say #206) successfully and included code as in (#206):
<Upgrade Id="$(var.ProductUpgradeCode)">
<UpgradeVersion Minimum="$(var.ProductVersion)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />
<UpgradeVersion Minimum="1.0.0.178" IncludeMinimum="yes" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Language="1033" Property="UPGRADEFOUND" />
</Upgrade>
Scenario is:
I have installed build #177 then upgraded to build #206. It is still allowed to install #177 which I want to prevent this downgrade.
From build #178 onward I have changed product GUID for major upgrade and which is working fine.
Please suggest how to prevent this. I don't want to downgrade build below 177. If I have done major upgrade on build no <= 177.
Your problem is the how the comparison of versions is done in MSI by default - 1.0.0.123 is treated the same as e.g. 1.0.0.33. You either have to increase your revision version to make the installer detect this as an older version or use a workaround.
You might for instance create a custom action to check against this very Revision version and place it e.g. before InstallValidate:
<CustomAction Id='MyVersionCheck' Return='check' (...) />
<InstallExecuteSequence>
<Custom Action='MyVersionCheck' Before='InstallValidate' />
</InstallExecuteSequence>
Some more information can be found in this article, for informations about how to create custom actions i'd recommend this blog entry as a starting point.