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.

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.