Join GitHub today
Setting to enforce different REINSTALLMODE flag than "o" for bootstrappers #5911
If this issue is a feature request:
As a installer author I want to enforce the installer to install files to the system regardless on their previously installed versions. By version I am referring to "file versions" as they are contained in DLLs and Executables. Currently the REINSTALLMODE is fixed to the flag "o - Reinstall if the file is missing or is an older version." among other flags and configuring the REINSTALLMODE is actively prevented (v3 and v4 have this behavior).
MSI provides various different flags to control how files are placed depending on their version but there is no way in WiX to tell Burn to use different flags.
It should be possible for installer authors to define how file versions are treated on the individual MSI actions in order to overcome issues when file versions shipped to the customer might differ from the "o" expectations.
There is an issue on upgrade installations that causes old files to be removed but new files not to be placed on the system. This issue can happen if newer versions of your product try to ship the same version of a dll like the old product version. An example:
On an upgrade from Product v1.0 to v.1.1 first the uninstall sequence removes Library.dll from the system but the installation sequence then does not put it again to the system as MSI somehow detected that the DLL is already on the system. Similar issues seem to happen if library authors decide to move to a new versioning schema and you suddenly have downgrades.
We also suffer directly from the scenario above. We have some internally developed libraries that do not change their version number during our development process. For some selected libraries (especially some .net libs that stay on 126.96.36.199 internally for some time) they appear to be missing quite often and the application crashes with missing dll errors.
Here are some references and discussions on this topic.
We do not have a workaround for this missing feature in place but https://stackoverflow.com/a/1919979/996233 sounds like a reasonable alternative. By supressing the file information to be generated, we could enforce the file versions to match the product versions achieving always a newer version of the DLL even though the file version is the same.
A new set of properties/attributes on the bundle tag could allow configuring the REINSTALLMODE property. I would not allow users to again fully manually set the REINSTALLMODE on the MsiPackage as it is dependent on the actions we are triggering on the MSIs (repair, modify etc.). Instead I would rather go for a bundle-level configuration with user friendly properties that define how file versions should be interpreted. Then in burn the user defined settings can be respected when building the REINSTALLMODE property in burn.