I have a very simple WiX project (version 3.7) that installs somes files (a .NET program version 6.0.0.0). I'm ready to release a new version 6.0.1.0 using the MajorUpgrade functionality in WiX.
I'm keeping the UpgradeCode the same in the Product element and I change the Version from 6.0.0.0 to 6.0.1.0
<Product Id="*" Name="MyApp" Version="6.0.1.0" Manufacturer="Me"
UpgradeCode="$(var.TheUpgradeCodeGUID)">
On a machine with 6.0.0.0 installed, I run the new installer.
The removal of the old version 6.0.0.0 runs ok (all installed files are being removed), but when the installer continues to install the new version, 2 files are missing: a 3rd party DLL and a 3rd party EXE (that haven't been changed) are not being reinstalled.
<Component Id="AutomaticUpdaterWPF.dll" Guid="*">
<File Id="AutomaticUpdaterWPF.dll" Source="AutomaticUpdaterWPF.dll" KeyPath="yes" Checksum="yes" />
</Component>
<Component Id="wyUpdaterProgram" Guid="*">
<File Id="wyUpdaterProgram" Source="wyUpdate.exe" KeyPath="yes" Checksum="yes" />
</Component>
All other files in the < ComponentGroup > (some modified, some unmodified incl. other 3rd party DLLs) are being installed correctly during the major upgrade.
If I click on "repair" after the major upgrade, the 2 missing files re-appear.
Also, if I install version 6.0.1.0 for the first time (no upgrade, but first installation on a clean machine), then those 2 files are installed directly and normally.
(tested on several Windows machine (XP, 7 and 8)
Anybody any suggestion what is wrong and how to fix it?
The log file provided shows that newer versions of a few files already on the machine:
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {015A4DC1-56F4-562B-96B5-B3BE0D45FA5F} since the same component with higher versioned keyfile exists
MSI (s) (0C:5C) [16:13:25:890]: Disallowing installation of component: {4B6A1404-3892-5BEF-AB47-8FE3149211A4} since the same component with higher versioned keyfile exists
I've seen this problem with this updater in the past. Christopher is correct. The updater updated its files but didn't tell the MSI (it doesn't update the MSI which is not the correct thing to do). The new MSI thinks newer stuff is on the machine, chooses not to install its files, but during the upgrade the old package removes the files (it doesn't notice that the versions are newer). Since the new installer chose not to install the files you end up with nothing... until the repair.
To work around the problem, you need to move your RemoveExistingProducts action later. If you're using the MajorUpgrade element then Schedule='afterInstallExecute' or Schedule='afterInstallFinalize' should do the trick. You'll need to be more careful with the Component Rules.
Also, IMHO, the 3rd party vendor should not be updating files outside of the MSI. Their decision is forcing your product into a particular way of upgrading.
A log file would help. My guess is it's based on where you have scheduled RemoveExistingProducts. I've seen situations where Costing figures out a file being installed is the same as a file already installed and decides to not install the file. Then the major upgrade occurs and you end up not having the file. The repair works because the file isn't there and costing realizes that it needs to be installed.
I have had the same problem. The issue here is when doing major upgrade, msi at first checks which components to install (and all dlls with lower version than the ones already installed are marked as "do not install"), then it removes installed app and then installs new version but without those previously marked components.
Rescheduling of REP did not help since "disallowing installation (...)" was done in Costing phase and MajorUpgrade can only be scheduled in Install phase.
My solution was to set REINSTALLMODE property to "amus" in wxs file.
<Property Id="REINSTALLMODE" Value="amus" />
The "a" means all dlls will be reinstalled despite their versions.
I had another solution to this problem, but the previous reply certainly pointed me in the right direction. The DLLs in my .NET project were being assigned a lower version number than my previous installation. Going to the AssemblyInfo.cs files and incrementing the third octet from 0 to 1 solved it. Wix now recognized the DLLs as newer.
[assembly: AssemblyVersion("1.0.1.*")]
Error still exists on installer 5.0 and is still a problem.
Workaround to place RemoveExistingProduct after InstallFinalize is no solution for us. I forced the update by property setting on the single file.
This solution works for us now.
On older versions of Windows Installer the issue is documented here:
https://support.microsoft.com/en-us/kb/905238
The list of affected products inplies that it's fixed in MSI engine 4.0 and later. Using the 4.5 redistributable before doing installs should help, if applicable to the OS version.
Related
This problem, in fact, is to avoid a problem I will not solve
When I install my product once and I use the MSI again, the unloading process is performed.
However, this does not remove residual information from the registry, which must be cleaned Up using "Windows Installer Clean Up", and when reinstalled, a registry permission issue occurs.
I saw the Checking for Oldies, However, it was found that FindRelatedProducts only performed on the first installation, that is, when I installed the MSI again, FindRelatedProducts did not.
<Upgrade Id='YOURGUID-7349-453F-94F6-BCB5110BA4FD'>
<UpgradeVersion OnlyDetect='yes' Property='SELFFOUND'
Minimum='1.0.1' IncludeMinimum='yes'
Maximum='1.0.1' IncludeMaximum='yes' />
<UpgradeVersion OnlyDetect='yes' Property='NEWERFOUND'
Minimum='1.0.1' IncludeMinimum='no' />
</Upgrade>
<CustomAction Id='AlreadyUpdated' Error='Foobar 1.0 has already been updated to 1.0.1 or newer.' />
<InstallExecuteSequence>
<Custom Action='AlreadyUpdated' After='FindRelatedProducts'>SELFFOUND</Custom>
<Custom Action='NoDowngrade' After='FindRelatedProducts'>NEWERFOUND</Custom>
</InstallExecuteSequence>
So I'd like to ask you guys
How do I check every time I run MSI when I have installed it? Is it installed and the same version, If the same version has been installed, exit the installation process.
When you run the "same" MSI again it goes into maintenance mode, often just a repair. Windows doesn't even need to use the MSI you use for this "install" because it uses the original MSI for the install, which may or may not be the one you attempt to install again. So it's not clear what you mean by "the unloading process" or what you expect running the same MSI to actually do.
FindRelatedProducts is for major upgrades, but that means incrementing the ProductVersion and changing the ProductCode. Running the same MSI does not cause a major upgrade (see WiX MajorUpgrade element).
So again, what are you expecting to happen when you run that same MSI again? It seems that you are not uninstalling it, so it will go into maintenance mode using the original MSI file, so there is nothing you can do to change that behavior because it's embedded in the installed product's MSI. Since you are apparently not uninstalling the installed product, it won't remove its registry entries. You should say what those residual registry entries are and why they are residual if in fact the product is not being uninstalled.
MSI Zapping: I am not sure what exactly you have done - you seem to have zapped your installed MSI - which is not recommended at all. It can cause serious problems - up to and including total MSI database corruption in the registry.
However, first things first:
MajorUpgrade Element: You can use the more convenient MajorUpgrade Element instead of the older-style elements you are using. Here are the older-Style Upgrade Elements in use. Directly below is a sample of the more modern, MajorUpgrade convenience element in action:
<MajorUpgrade Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
AllowDowngrades="no" AllowSameVersionUpgrades="no" />
Maybe try this element instead of those you are using. Just comment the old ones out and replace with this simple element. If you do this correctly your major upgrade should work "out of the box". Make sure you specify an UpgradeCode in the Product Element. See the documentation for major upgrades
Relevant Links:
How to implement WiX installer upgrade?
Upgrading a WiX generated package with major version zero
How to implement WiX installer upgrade?
I did not fully understand this section of your question: "When I install my product once and I use the MSI again, the unloading process is performed. However, this does not remove residual information from the registry, which must be cleaned Up using "Windows Installer Clean Up", and when reinstalled, a registry permission issue occurs".
Zapping: What exactly did you do? Zap the installation? Why? You should be able to successfully uninstall from Add / Remove programs? Did that uninstall fail? What is the error message on reinstall?
Modify / Repair: MSI will detect when it is already installed in the same version auto-magically. You will then see the setup's modify / repair dialog show up, and not the first time installation dialogs.
These modify dialogs only show up if you double click the original MSI files used to install, without rebuilding it. Or you invoke modify from Add / Remove Programs.
If you rebuild your setup, it will have a new package GUID at the very least, and MSI will then detect that the freshly built MSI is not the one that is already installed, and an error message shows up. Now you can uninstall the current version from Add / Remove programs.
Related Products: An MSI will also detect if there are related versions installed if you correctly author the Upgrade table - as you seem to do.
If you generate a new product GUID each time you compile, you will be able to install the new version "on top of" or "side-by-side" with the older installation, unless you author the upgrade table - in which case the older version should be automatically uninstalled as part of the new version's install.
You need to understand package code, product code and upgrade code. The package code is auto-generated for every compile and build. The product code you can set to auto-generate by setting it to * in the product element, or you can hard code it and change it as required. The upgrade code should stay the same once defined. Please google the difference between these different codes - I don't have time to wrap up this explanation right now.
I have a project with a lot of MSIs (installed with a bootstrapper). Recently, after a major upgrade, I noticed that the previous version wasn't being uninstalled in Programs and Features (Win 7). That is, after upgrading from Version 1 to Version 2, both Version 1 and Version 2 are in Programs and Features.
This is a common problem, but it's a problem with a lot of different shades of grey -- I have an uncommon shade of this problem.
The problem may lie in a specific MSI. This MSI can only run during the initial install. Therefore I never change its version number. Here is what it looks like (to show that it's a legit Major Upgrade):
<Product Id="*"
Name="MSI"
Language="1033"
Version="1.0.0.0"
Manufacturer="Bob"
UpgradeCode="GUID-HERE">
<Package InstallerVersion="200"
Compressed="yes"
InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate EmbedCab="yes"/>
<FeatureRef Id="ReferenceToFeature"/>
</Product>
Here's why I think this is the MSI that's causing the problem: when I run the major upgrade, I have Version 1 and Version 2 in Programs and Features. When I run the uninstaller with verbose log, I can see that it uninstalls all of the MSIs, in that I get the boostrapper uninstall log file, then I get separate uninstall log files for the rest of the MSIs.
If I look at the log file for this MSI, I noticed a problem. Here's the part of the log file that I think may be the problem:
...
PROPERTY CHANGE: Adding INSTALLLEVEL property. It's value is '1'.
Disallowing uninstallation of component: {GUID-HERE} since another client exists
Disallowing uninstallation of component: {GUID-HERE} since another client exists
...
I recognize the GUIDs. They are GUIDs for components in my MSI. I know that this means that another program is using the resource -- that's why it won't uninstall -- but for the life of me I can't think of what program that would be! I'm installing on a clean virtual machine, and the program that my installer installs isn't running when I uninstall!
Some more info that makes me think that this MSI is causing the Programs and Features doubling-up: after I uninstall Version 2, I'm left, of course, with Version 1. When I uninstall Version 1 with verbose logging, the only log for an MSI that pops up is for the MSI in question! No other MSIs are uninstalled during that uninstallation.
I've tried adding the attribute AllowSameVersionUpgrade="yes" to the element to the MSI -- this
<MajorUpgrade AllowSameVersionUpgrade="yes"
DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
-- and that actually breaks my installer, because it makes the MSI install during the update installation, where I only want the MSI to install during the initial installation. It also doesn't fix the problem, in that both version still show up in Programs and Features.
However, it does cause the MSI to be uninstalled the first time through. That is, before, when I didn't put in the AllowSameVersionUpgrade="yes" attribute, the MSI wouldn't successfully uninstall during Version 2 uninstallation, and then when I uninstalled Version 1 I would get a log file uninstalling it. When I add the attribute, I still get the doubled up versions in Programs and Features, except this time I can uninstall the MSI during the first uninstallation, and then, during the second uninstallation (the version that shouldn't be there in the first place), I don't get any MSI log files -- all I get is the bootstrapper log file.
Can anyone shed light on this problem?
OK! I managed to recreate the problem in a toy program, so, hopefully, solving this problem should be much simpler!
Mr. Asmul, I appreciate your interest. However, I solved the problem. I made a very, very dumb mistake that I'm far too embarrassed to admit. Safe to say I've been chasing my own tail for two days and costing my employers money because... well, I was dropped on my head as a baby, and as a result I'm none too bright.
Your problem is indeed common, at least on the face of it, but I don't quite understand the whole problem scenario. When you have two versions of the same MSI in add/remove programs your major upgrade has failed. When you then uninstall one of the versions, you will get the log file entry you indicate:
Disallowing uninstallation of component: {GUID-HERE} since another client exists
Essentially each MSI component is installed twice with a ref-count of 2 because two versions of the same MSI is installed. Uninstalling both MSI setup versions should correctly remove the components in question (because then the ref-count goes down to 0 for the components).
"This MSI can only run during the initial install" - what does this mean exactly? I have read it again, and I am afraid things are just not clear to me.
These other MSI files, the suite - what are they, what do they install, do they install to the same or different locations? Why are they separate MSI files if they always install together?
Please prefer to update your question rather than adding too many comments.
While not strictly the same as the question, I'll add a variant of the same problem. I was using my own custom bootstrapper application (BA) and getting the same problem. This was because I hadn't added support to the BA to process command line args and run silently. Specifically the upgrade will run the old BA telling it via the command line to run silently and do an uninstall (which I wasn't handling).
As an aside if you are implementing your own BA, I highly suggest you download the WIX source code as it also implements a custom BA.
PS: This thread provides a range of options for getting upgrades working correctly. Note that some of the options like using the Upgrade/UpgradeVersion pre-date other options like the MajorUpgrade element.
How to implement WiX installer upgrade?
I have a bundle which installs two products: the application and a much larger resources installation.
For upgrades the application msi will apply a standard upgrade, but the resources installation gets patched instead. (Unfortunately this process started a while ago, so the patch chain is still built using Wix 3.0).
On uninstall of the bundle the application is fully and correctly uninstalled, but the patch only is removed, leaving the full install of whatever previous version of the resources existed (downgrade from 1.5.0.0 to 1.4.0.0).
Is there a method to force a full uninstall of the full product, rather than just the .msp patch, through the bundle?
Edit: Just to add, exposing the resources installation in Programs and Features and running an uninstall there will remove the entire product correctly as expected.
I think this could be a possible solution for you.
I just tested myself a very simple bundle with one MSI in it. What I did was have the main bootstrapper installer have the msi embedded in it an install it. The second bundle had a higher version and the exact same msi reference but I set compressed="no" in the <MsiPackage> tag. When I uninstalled the upgraded bundle it also removed the original MSI.
So I think you can get your bundle to properly remove the original "Resources" installation after you've upgraded and added a small msp. You just need to add back the <MsiPackage> to the bundle chain before the msp and set compressed="no"
<MsiPackage SourceFile="$(var.ResourcesInstaller.TargetPath)" Compressed="no"/>
The only caveat here is that the SourceFile should be the exact same msi that was included in your first install. When you install the upgrade, the burn engine should detect this msi as already installed so nothing would be needed to be done. When uninstalling, it will detect the msi as installed and should uninstall it.
I'm not completely sure this will work but it is something to try. Another nice thing about this is it will have virtually no impact on the size of your upgrade installers.
We are upgrading our WIX msi installer (not a bundle) with manual pre-requisites to a Managed custom Bootstrapped application Bundle. The boot strapped custom installer bundle exe works fine for fresh installs. But if we want to upgrade our older product which is just an msi, we are in trouble. This is what I am trying to do
Detect RelatedMsiFeatureHandler detects there is an older msi package installed.
I am handling the Plan events for individual packages and setting the states as desired. For ex: state = Present for install
I cannot to Apply(UpdateReplace) because I do not have an older Bundle,
The million dollar question is how do I upgrade this msi package?
Any help is appreciated.
Thanks
All I had to do was set the MsiProperty UPGRADE=1 in Bundle.wxs for the relevant Msi Package in the chain. This made sure that when the Bundle.exe is run the specific msi is upgraded BTW: this is the first version of Bundle for us. We had just an MSI before for installation.
<MsiPackage DisplayName="Installing Main Product" SourceFile="$(var.Path_Setup)" DisplayInternalUI="no" SuppressSignatureVerification="yes" >
***<MsiProperty Name="UPGRADE" Value="1"/>***
<MsiProperty Name="NAS_PATH" Value="[NasBackupPath]"/>
<MsiProperty Name="NAS_BAK_TIME" Value="[BackupTime]"/>
</MsiPackage>
</Chain>
Just in case if anyone having similar issue (WIX 3.10)
this statment under the installer's Product will resolve the issue. You must update the version of the product and product upgrade code must be same with previous install.
"AllowSameVersionUpgrades" = yes will make sure not to install same product side by side.
The situation:
I have a WIX-based bootstrapper installer, which installs my msi package and (some) prerequisites (.NET). The installer is .exe and it works ok.
Now, some clients want to install msi, especially in corporate environments where they can push it centrally.
It looks easy, just give them the msi. Again, It works ok.
Now, the problematic part.
When the application is installed from MSI, and later upgraded to newer version from .exe installer, there will be two ARP entries. And vice-versa - when the application is installed from .exe, and later upgraded from MSI, there will be double ARP entries again.
Is there any easy/standard solution?
To maintain the visibility as Bundle: visible, MSI: not visible, you can either:
Install the upgrade the same way that the bundle does, passing ARPSYSTEMCOMPONENT=1 to msiexec, or
Change your MSI Product so that it defaults to not visible: <Property Id="ARPSYSTEMCOMPONENT" Value="1" />
(In your bundle, MsiPackage/#Visible seems to effectively be "no", which is the default.)