New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting to enforce different REINSTALLMODE flag than "o" for bootstrappers #5911

Danielku15 opened this Issue Nov 26, 2018 · 0 comments


None yet
2 participants
Copy link

Danielku15 commented Nov 26, 2018

Feature requests

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.

  • Describe the scenario and benefits that the feature supports.

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:
Product v1.0 ships Library.dll with version
Product v1.1 ships Library.dll with version

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 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.

  • Describe how you're accomplishing the feature today (if possible).

We do not have a workaround for this missing feature in place but 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.

  • Describe what you'd like the new feature to do.

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.

@barnson barnson added this to the v4.x milestone Dec 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment