MSI does not install all files when RemovePrevious

问题:

I have a MSI build using WiX version 3.

All previous installers for the product we are deploying worked fine with the configuration specified (that is: if previous version exists, remove, then install the new version) - however, the new MSIs we build don't install all files when it runs through the 'remove first' path.

If we manually remove the existing installation and then run the new version all the files are installed - and when I examine the MSI file in Orca the files and features are shown and seem to be fine.

We have tried running with verbose and extra logging turned on (/l*vx) however all we can see if that the files are not being registered & then installed.

Any thoughts or suggestions? This is driving us up the wall.

回答1:

Based on the default custom action sequence, Windows Installer determines which files need to be installed/overwritten before removing any existing versions of software. Windows Installer uses the value of the REINSTALLMODE property to tell it how to make decisions about when to overwrite files. If REINSTALLMODE contains an "o", then it will only install files where the version is different or the file doesn't already exist; non-versioned files will only be installed if the Modified Date of the file is <= the Created Date (i.e. the file is not modified). If the REINSTALLMODE contains an "a", it will always install the file, regardless of any version or date information attached to existing files.

What is happening in your scenario is most likely the following:

1. Windows Installer determines which files to install. It decides that some files don't need to be installed (possibly because they already exist and are of the same or newer versions as the ones in the MSI).
2. The previous version of software is removed, including the files Windows Installer determined didn't need to be installed.
3. Windows installer installs files for the new installation, but does not install files that it determined did not need to be installed.

The end result is that a bunch of files are missing after upgrading the software. Setting REINSTALLMODE=amus instead of omus will likely fix your problem, but you should make sure you know how this affects the rest of your installation. If there are any files that you don't want to be overwritten, you will need to mark those components to "Never Overwrite".

回答2:

OK, well talking to someone else where I am helped me find a solution to the problem.

We added the property REINSTALLMODE and set it to amus. What does this mean?

By default the property is set to omus which means: Reinstall if the file is missing or older, rewrite registry for machine and user hives, reinstall shortcuts. Changing this to amus basically says: Reinstall all files.

So, not 100% sure what the cause was - I suspect there may have been strange locks or something, but setting to amus doesn't being on any adverse effects, so we'll stick with that.

Thanks for the suggestions.

(Also, more details on this property can be found here: MSDN: REINSTALLMODE Property

回答3:

What does your <RemoveExistingProducts After=""> step look like? It could be that the removeexisting is running after the install -- and removing all files that were the same in the previous and current versions.

I have my installer set to <RemoveExistingProducts After="InstallInitialize"> to make sure it's done before anything else. I don't know if it's right or not, but it seems to work.

    <Upgrade Id="$(var.UpgradeCode)">
        <!--Upgrade code found at http://www.nichesoftware.co.nz/blog/200809/upgradable-msi-installations-with-wix -->
        <!-- Detect any newer version of this product-->
        <UpgradeVersion Minimum="$(var.version)" IncludeMinimum="no" OnlyDetect="yes" Language="1033" Property="NEWPRODUCTFOUND" />

        <!-- Detect and remove any older version of this product-->
        <UpgradeVersion Maximum="$(var.version)" IncludeMaximum="yes" OnlyDetect="no" Language="1033" Property="OLDPRODUCTFOUND" />
    </Upgrade>
    <CustomAction Id="PreventDowngrading" Error="Newer version already installed"></CustomAction>
    <InstallExecuteSequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
        <RemoveExistingProducts After="InstallInitialize" />
    </InstallExecuteSequence>
    <InstallUISequence>
        <!-- Prevent Downgrading-->
        <Custom Action="PreventDowngrading" After="FindRelatedProducts">NEWPRODUCTFOUND</Custom>
    </InstallUISequence>

回答4:

I know this is an older thread, but I encountered a similar problem that was not covered by the solutions. In my case, I had a DLL that was actually a lower number version than its predecessor. This DLL would never appear on an upgrade install. Running

msiexec /i myproduct.msi /l*vx install2.log

and checking the log showed that the file never was installed. It just did not appear in the log as one of the files installed. The MSI definitly contained the file, the best evidence being that a Repair would place the file. Also, exploding the MSI with various tools showed the file present. A straight install on a clean machine would always work.

This did not help:

msiexec /i myproduct.msi REINSTALL=ALL REINSTALLMODE=amus /l*vx install3.log

I am building the MSI with Wix, and I have been using this script for many years. Most recently we set the script to completely delete the old directory in our 5.3 version. This had worked to 5.2 -> 5.3 and 5.3 -> 5.4 upgrades. But with the 5.5 version, the DLLs were all rebuilt with new versions of the DLLs. The DLL projects were hosted in GitHub. The build script for this particular DLL was set to be an assembly version of '10.0.0.{git rev-list --count HEAD}'. The project had been moved, causing the HEAD count to go from 444 to 30.

The wixscript include has this,

define ProductGuid = "{nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn}"

so we update the product guid (not the product upgrade guid) on each release.

The remedy was to slightly change the build script of this dll to set the assembly version to go to '10.0.1.{git rev-list --count HEAD}', presumably being treated as a higher numbered version.

Why this worked, I am unable to explain.