WiX upgrade question - file's major version was incremented, but revision is lower, now old file removed, yet new file is not copied during upgrade

Question

I automatically generate a WiX file for my installer based on a directory (it's for a web app), and it includes references to the following 3 .Net assemblies:

• Migrator.dll
• Migrator.Framework.dll
• Migrator.Providers.dll

And here is the generate WiX fragments:

<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.dll" Guid="*">
    <File Id="bin.Migrator.dll" Name="Migrator.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.dll" />
  </Component>
</DirectoryRef>
</Fragment>
<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.Framework.dll" Guid="*">
    <File Id="bin.Migrator.Framework.dll" Name="Migrator.Framework.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.Framework.dll" />
  </Component>
</DirectoryRef>
</Fragment>
<Fragment>
<DirectoryRef Id="bin">
  <Component Id="bin.Migrator.Providers.dll" Guid="*">
    <File Id="bin.Migrator.Providers.dll" Name="Migrator.Providers.dll" KeyPath="yes" Source="..\WebApplication\bin\Migrator.Providers.dll" />
  </Component>
</DirectoryRef>
</Fragment>

We have been using the same basic installer structure for a year or so, but recently we updated the Migrator.Net libraries to a new in-house build that saw the version numbers and assembly title/description attributes change from (dumped out of Orca)

• bin.Migrator.dll bin.Migrator.dll Migrator.dll 16384 3.0.1317.0 0 512 78
• bin.Migrator.Framework.dll bin.Migrator.Framework.dll pi0mozkr.dll|Migrator.Framework.dll 20992 3.0.1317.0 0 512 79
• bin.Migrator.Providers.dll bin.Migrator.Providers.dll jq05waoy.dll|Migrator.Providers.dll 73216 3.0.1317.0 0 512 82

To, after upgrading the libraries:

• bin.Migrator.dll bin.Migrator.dll Migrator.dll 16384 3.2.0.1 0 512 55
• bin.Migrator.Framework.dll bin.Migrator.Framework.dll pi0mozkr.dll|Migrator.Framework.dll 28160 3.2.0.1 0 512 56
• bin.Migrator.Providers.dll bin.Migrator.Providers.dll jq05waoy.dll|Migrator.Providers.dll 79872 3.2.0.1 0 512 57

Though the minor version is higher, the revision is now 1 instead of 1317.

Since then we have found that upgrading to the new version results in these 3 files not being copied (so the upgrade process removes the old files, but does not install the new files).

Would this be related to the version number of the assemblies changing, and if so is there any way to override this behavior (we just want to remove everything, then copy everything fresh, regardless of version).

Interestingly if you install, then re-run the installer and do a "repair" it does copy the new files across - I assume this is because when repairing the file is no longer there, so the file version check logic doesn't apply?

Any hints as to both how this works, and how to avoid the upgrade issue we are having would be greatly appreciated.

Ruby

Found a similar question here: #4227956 (slightly different scenario) - but still the same issue, how can you work around this, without changing the version of the assembly. – Ruby

Answer 1

As the linked question suggests, you can try to re-schedule RemoveExistingProducts so that the old product is removed before any new files are installed, like this:

<InstallExecuteSequence>
    <RemoveExistingProducts After="InstallValidate" />
    <!-- other actions -->
</InstallExecuteSequence>

Another option is to modify REINSTALLMODE property, and replace e mode with a, that means its value would be amus. This way all the files will be re-installed, the operation would take longer but rather more reliable.

Afterpiece

Changing the order of events is not an option for me, but changing the REINSTALLMODE is exactly what I want - install time during an upgrade is really not an issue for us, we just want to ensure all files are installed correctly. – Ruby

This answer is not helpful. The suggested placement of RemoveExistingProducts after InstallValidate doesn't help. Setting REINSTALLMODE to amus is very dangerous because a force re-installs ALL files, including shared system files that you might want to not downgrade. For example, imagine you have some merge modules that install system runtime DLLs. These DLLs are later patched with a security patch by the vendor. When your package is later installed with amus, you'll overwrite the newer, safer DLLs from the vendor. – Cassation

Re-scheduling RemoveExistingProducts as shown does not solve the problem. During costing (which is before RemoveExistingProducts), MSI sees that a newer version is present, and skips the file. You'll see Disallowing installation of component: XXX since the same component with higher versioned keyfile exists in the log. – Lewendal