WIX MSI defining to force overwrite or to never overwrite files

Question

We have created an MSI using WIX. When we update the software with a new MSI (with a new version) we want to overwrite dll's with a newer file creation date, and we want to keep certain userconfig xml files.

The wix config we already applied:

1. <RemoveExistingProducts After="InstallFinalize" /> to set file deletion after setup.
2. <Component NeverOverwrite="yes"> to force the installer not to overwrite certain files.
3. <File DefaultVersion="2.0.0.0" /> to force the installer to overwrite certain files.

We managed to make the installer force files not to overwrite by applying above 1 and 2. How can we manage to make the installer force files to overwrite? The above 3 options doesn't solve the issue for us.

Thank you for your answers!

Answer 1

There is no built-in "overwrite files because they are newer date" functionality in Windows Installer (or in its hotfixes, service packs or anything else). The rules are based on file version -higher overwrites lower - so the best long term solution is for you to have file versions, and increment them when you build a changed binary. Then it all just works. The same is true of data files. If they were altered after the initial install, then they will not be replaced. Every MSI install I know of takes advantage of these two rules because then it all just works.

https://msdn.microsoft.com/en-us/library/aa367835(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/aa370531(v=vs.85).aspx

So you are inventing your own version control/overwrite scheme.

If the binaries actually do have a version, then WiX will use it at build time despite DefaultVersion (there is a suppress files option you didn't mention) and Windows will use it at install time, so if your files are versioned then version rules will be used. If the binary files have no file version at all then they will be treated like data files, so in that case you should tell WiX to use the file hash mechanism, because Windows will replace data files if the incoming one has a file hash that is different to the installed file:

https://msdn.microsoft.com/en-us/library/aa370532(v=vs.85).aspx

So if 3) is your only problem, use file hash if they have no file version, otherwise it's unsafe to lie about the version of the file. If the actual version of the file you are installing is 1.0.0 and the one on disk is also 1.0.0 and you lie and say that the incoming version is 2.0.0 then you're in a situation where the file on disk is 1.0.0 and the version in the File Table in the MSI is 2.0.0. In other words Windows Installer might notice that the installed product is broken (the wrong versioned file is on disk according to the File Table) and may attempt to repair it with its resilience features. As it says here, "Correctly populate....the Version... in the File table":

http://blogs.msdn.com/b/heaths/archive/2005/12/02/499495.aspx

because you may see a prompt for the original source MSI file if it doesn't match the file on disk.

So you're not in a good place with 3) because version lying is not a solution, but file hash would work if you have no version at all in the binaries. In general you really should be using the overwrite rules that Windows supplies instead of creating your own. If you were to do that then 1) Higher binary versions overwrite lower versions and 2) Files updated since they were installed don't get overwritten. Using these rules would be a better approach.