wix major upgrade not installing all files

Question

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?

Cumine

Have you tried running the install with verbose logging to see why they aren't being installed? – Loge

The installation log file is here: pastebin.com/tsf9C1pS – Cumine

Answer 1

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.

Nephridium

Hi Rob, thanks for this impressive analysis. Your solution works! Futhermore, you've pointed me in the right direction of the root cause of the problem. On a build machine, the AutomaticUpdater.dll was in fact automatically updated to a higher version than on my development machine on which I was creating the new build/installation. The result is exactly like you described. Your solutions works & after upgrading the development machine to the same version of the 3rd party tool as on the build machine, I could also resolve the issue. This is someting for me to be very careful of in the future. – Cumine

I saw this type of problem a lot at Continental Airlines where we had apps in production that were initially deployed with tools like SMS / Wise and the app team was doing their own auto updates outside of the official delivery vehicle. I'd have to do a "forced uninstall" to clean the baseline for MSI to go down and then beat the app teams over the head for their auto update antipatterns to finally close the MSI loop. – Chalutz

Champion! Thanks Rob, saved hours (days?) of heartache for me no doubt. – Hydrophane

Does anyone know how to solve this issue in a Visual Studio Setup project? (.vdproj file). This just started happening for me (using similar projects for 3+ years) – Dulse

Answer 2

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.

Fritts

Answer 3

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.

Chalutz

The installation log file is here: pastebin.com/tsf9C1pS (hopefully this helps) – Cumine

Yes, it would have helped. My guesses are usually spot on though. :) – Chalutz

Answer 4

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.*")]

Escapism

Answer 5

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.

Forrer

How did you do that? – Mimesis

Answer 6

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.

Janijania

This link is dead – Broker