I am using Major upgrade early scheduling in my WIX Setup projects as below.
I prefer to clear all files on upgrades. However I need to preserve a config file and restore again on upgrade.
I don't want to change this early scheduling (Schedule="afterInstallInitialize"), as I will be ended with other issues. Is there any work around (Custom Actions?) to preserve the config file in the above early scheduling?
The way I deal with this problem is to have two files. You'll notice that app.config/web.config files appSettings element has a file attribute. If you store your user data there the installer will never know about it and will never remove it or otherwise harm it.
web.config ... never modify this... always let the installer overwrite it / remove it. Think of it as stock | virgin file data that the installer owns.
appsettings (connection strings to) override... put your data there and you'll never have to do gymnastics to preserve the data.
Preserving Settings: What kind of settings file is this? And where is it stored? In the user profile or maybe in a shared, per-machine location? Perhaps it is a web-application and it is the web.config file?
Previous Answers: This question comes up all the time. Here are some answers from before that are directly or more vaguely related:
Permanent Component: When you do early uninstall and wipe out all previous files, the only option that really works would be to set the config file permanent from "now on". It won't work for the first update, but for future updates the file will be preserved on disk.
Minor Upgrade: If you migrate to this new version using a minor upgrade instead of a major upgrade, then the file will not be removed during the upgrade since the minor upgrade does not trigger uninstall but upgrades the product "in-place". It can be a challenge to deal with updates in the future since some people may not have upgraded to the minor upgrade version, but will seek to major upgrade directly from version 1 to 3. If they do the settings file will be wiped out by version 1 uninstalling itself. Practical issue that ruins the gig.
Custom Actions: Many try to back up the settings file using custom actions during the new update and then to restore the file after the upgrade is complete. Error prone, but doable. Complexity can be witnessed here: Wix Tools update uses old custom actions.
Download Settings: My favorite approach is to change the settings file to be downloaded from a database or an URL by the application itself. "Clouding settings" I like to call it. That yields a reliable, online repository for settings that can be shared across computers (not always desirable). If you retrieve from a database you can also provide version control / revisioning and rollback for settings.
Some Further Links:
