How does your application work? Does it write settings to these XML files over time, and you hence want to preserve them? If so, where are they stored? In a per-machine or per-user location?
Let me try to describe some problems for you that you are likely to face - and you could not possibly foresee ahead of time (without testing).
Some details about file overwriting
File versioning rules: MSI has built-in support to not overwrite non-versioned files that have been modified since installation (the create and modify dates are different). These are "File Versioning Rules". They are somewhat complicated and strange - you should definitely read the linked content - the real McCoy. So modified non-versioned files should not be replaced during updates - but there are many complications and bear-traps - and most people seem to fall into one of them.
Major upgrade file reversion: Perhaps the most common complication seen for "unexpected file overwrite" is not an overwrite at all. It relates to major upgrades - or installing your next product version if you like.
If you use a major upgrade to install your next version, and you schedule RemoveExistingProducts early in the InstallExecuteSequence, then all files are actually uninstalled and then reinstalled in their original version. They will appear to have been overwritten, but they have been uninstalled and then installed "fresh" instead.
This is all due to the very strange decision that MSI will happily uninstall modified files, even if they qualify to not be overwritten. What you need is a way to define the files to not be uninstalled at all. Which brings us to the next point:
Permanent and Never Overwrite Flags: Each component has two important settings relating to file overwrite and file preservation: the never overwrite flag and the permanent flag. This is indeed a good way to indicate that a file should not ever be replaced, nor uninstalled. However...
Setting only the never overwrite flag will not help against the major upgrade problem described above, the file is still uninstalled and then reinstalled so it appears overwritten (but is reverted).
If you set the permanent flag only, the file will be overwritten according to the File Version Rules - provided no modification is specified at the command line using features such as REINSTALLMODE (see section below). (I will need to verify this again to be 100% sure. There are many factors: component can be set permanent in older or newer setup only - or in both setups, major upgrade can uninstall early or late, REINSTALLMODE has many flavours, etc... Each variable can change the overwrite behavior)
In other words setting both the permanent and never overwrite flags is recommended to protect settings files.
REINSTALLMODE: REINSTALLMODE is a "modifier" or disabler of the File Overwrite / Versioning Rules (symantec). It is possible to set the REINSTALLMODE property during installation equal to amus - which will (among other things) force overwrite all files during installation regardless of the above mentioned file version rules.
Explanation of the amus REINSTALLMODE parameters:
a - Force all files to be reinstalled, regardless of versionm - Rewrite all registry keys that go to HKLM or HKCUu - Rewrite all registry keys that go to HKCU or HKEY_USERSs - Reinstall shortcuts and icons
One of these days I will write up issues with REINSTALLMODE and its implementation. It is an incredibly destructive concept in MSI, and it should never, ever be used. The problem is that this is a generic command line that can be passed to any MSI package and applies for the whole setup (why couldn't it at least be per feature?). I want to make my packages abort if amus is specified. Let me jot down quickly a few of the issues:
- Downgrade: Can downgrade shared files system-wide. The files can come from merge-modules so people might not realize they target system folders. Windows 10 protects its OS-files pretty well now, but there are other files that can still be downgraded without OS-protection.
- Inconsistent Versions: Can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files.
- Settings Wipe-out: Can downgrade or wipe-out settings in non-versioned files (and registry settings).
- Reboot Prompts: Can cause a significant increase in the number of requested reboots due to attempts to needlessly replace in-use files of the same version. There are features to avoid this, but they are often not used correctly. Restart Manager, more on restart manager.
- And then there was more...: There are several further issues that are quite specific. One day I will write them all up. I think. Maybe not? :-).
- Windows File Protection (WFP): Maybe I can add that certain legacy merge modules contain files that are now protected by the OS, and trying to replace them used to potentially trigger a runtime error. This is now handled by Windows 10 "silently".
- Registry: The
m and u switches of amus will reset registry data written by components (and not custom action code) outright irrespective of the a switch (At least this was the case last time I tried). High on my MSI anti-pattern list (see section "Potential Anti-Patterns").
- Unknowns :
GAC, WinSxS. I don't even known how things work with the GAC? Side-by-side is un-downgradable by design? One would think. Unless you poke around inside the assembly folder directly - which hopefully will trigger a runtime error - which I have not tried. In fact I don't think it will. See this issue with publisher configuration files (see all tweets in "thread").
This is all slightly mad to be honest, but it is how the technology works. So, let us stop complaining and try to deal with the problem. What are the options to deal with this?
Some options to deal with settings file-preservation issues
In summary I suppose you have a couple of options:
Use minor upgrades to upgrade your application. Then your files are never prone to be uninstalled and reinstalled and hence be reverted like they are for major upgrades.
A minor upgrade does not uninstall the existing installation - it upgrades it directly. Regular file versioning rules apply (modified non-versioned files are not replaced) - unless REINSTALLMODE is used to modify this logic.
However, few people succeed with minor upgrades only - they are too restrictive and limited. Close to none I would say.
Use a major upgrade with RemoveExistingProducts early in the InstallExecuteSequence and permanent and never overwrite enabled for the components hosting your settings files. When using a major upgrade the main choice is between early and late uninstall of the old version, and this choice has huge implications.
This section needs some cleanup. Will happen soon.... December 2019: and we are back. Years later. Some minor cleanup happened today - not much else. I shall keep promising to clean this up more. Empty promises makes the world go round and round. If this all seems like complaining, please read the major benefits of MSI (quick list). MSI delivered crucially important improvements to previous deployment technologies, but has a few big challenges left.
Early uninstall means that any component referencing errors you have made shouldn't cause any problems. They are more "forgiving" if you like. A lot of people end up using this approach specifically because is the most "forgiving" of component referencing errors and overall "robustness".
Early uninstall also means that modified files can be uninstalled and reinstalled during the upgrade, causing them to appear overwritten, but they are reverted (described above).
A remedy for the above problem is to set the hosting components for files to be permanent and never overwrite.
Early uninstall means that the complex component creation rules can be broken and your upgrade will still work. It is very common to break the component creation rules. If you use this approach you should set the files you want to preserve during upgrades to permanent and throw in never overwrite too. This should prevent the problem where modified files get uninstalled and fresh files are installed - yielding the impression that the files have been overwritten.
Use a major upgrade with RemoveExistingProducts late in the InstallExecuteSequence.
Late uninstall major upgrade installations do not uninstall and reinstall files that exist in the same location in the old and the new setups - and this works even when the files in question are not set permanent and never overwrite (allowing proper uninstall of the files as well - without any added, custom logic).
This kind of upgrade basically install as a "patch" - leaving files that are unchanged between releases untouched, and then upgrading other files according to the File Versioning Rules described above.
Rather they will be overwritten based on the normal file versioning rules (provided you did not set the REINSTALLMODE equal to amus - in which case you downgrade everything and wipe out settings).
Previous answer: How to keep a config file when major upgrade in wix v3.8?.
<stron
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
