Newer answers: 1) Companion files, 2) file version hack using Visual Studio, 3) moving the file to another installation path, 4) variations of REINSTALLMODE, 5) “version lying”, etc… All kind of options, most of which are not ideal:
-
File of a new component isn’t installed because there was an old component with the same file
-
How to Explicitly Remove dll During Majorupgrade Using Wix Toolset
Below is an older answer. I don’t think option 2 works properly anymore:
There are many ways – none are ideal.
1: You can use a companion file to force update of the file in question. Provided the companion file specified always gets updated, this may be the way to go. Essentially this means that you link the non-versioned file to the version update logic of its companion file (files are updated together). I have never used this in WIX, but I think it’s as easy as adding the CompanionFile attribute to a File element and point to the ID of the file you want to “version follow”. Inside the MSI file it will look something like this:
2: You can use a custom action to delete the file before file costing (or better yet, rename it to a backup format). The problem is that if the setup fails the file will be missing. If you rename the file instead of deleting you can put it back in case the setup fails via a rollback custom action. Sometimes I use the RemoveFile table to remove files on install, but depending on the sequencing specified in InstallExecuteSequence this may not work (deletion must happen before msi does file costing).
3: Then there is the sledgehammer approach: set REINSTALLMODE = amus to force overwrite all files regardless of version. I shouldn’t even mention this since it is horribly dangerous (you can end up overwriting system files, or on newer Windows versions trigger a nasty runtime error as files are protected). Use it only for dev testing, and don’t think it is a quick fix. It causes more problems than it solves.
As a variation, an acceptable approach may be to set the REINSTALLMODE to emus (replace older and same version files). This can help if you don’t want to increment the version numbers but keep rebuilding your binaries – as is the case in a lot of .NET. My guess is this will cause a whole new range of problems though – most significantly binary different but version identical files in the wild if you use it for public releases – a deployment smell if ever there was one. As a QA/DEV only approach it could work though. But seriously, why bother? Just auto-increment the build version of the binaries and the problem is solved reliably.
Links: