2

We use an XML configuration file with default settings in our application. The user can make changes to the settings in the UI but those are stored in another XML configuration file external to anything the installer is concerned about.

During installation, either through the installer UI or through an MST for unattended installations, values for settings are gathered and then written to the default settings XML file using util:XmlFile elements.

The issue we're having is during a repair, those changes are lost and the default settings are all set to empty values. We are not currently willing to replace how we store settings for the application, so please don't suggest alternatives for storing them like INI files, the registry, etc.

How can we preserve the changes during a repair? At a minimum, I'd like the repair to just not affect the XML file if it already exists but still put it back if it's missing (even if it was with the empty values). Optimally though, the repair should do what it's supposed to and put everything back to how it was immediately after initial installation.

Dewey Vozel
  • 2,257
  • 1
  • 19
  • 22
  • In the interest of simplicity and without having tried it, could you set the `NeverOverwrite` and `Permanent` flags for the component? Not sure WiX obeys them and I don't have time to test anything now, but it is very quiet in this tag right now so I thought I'd just lob you some ideas. A couple of links too: [reset config](https://stackoverflow.com/q/53583750/129130) and [quick test sample](https://stackoverflow.com/a/49162863/129130). – Stein Åsmul Dec 13 '18 at 02:26
  • Thanks for the suggestions Stein. NeverOverwrite works great for fixing the problem with Change and Repair but introduces another problem when doing an upgrade... the installer detects the file is already there and doesn't schedule it for installation. Then the uninstall runs and removes the file so in the end, the configuration file is just gone after an upgrade. The Permanent flag isn't an option because WACK will complain that files remain after an uninstall and we certify the app. – Dewey Vozel Dec 13 '18 at 12:39
  • I decided to just not support the repair option by disabling it: ``. I also tried to add a condition to the component like `<![CDATA[WixUI_InstallMode <> "Change" AND WixUI_InstallMode <> "Repair"]]>` but that didn't work. – Dewey Vozel Dec 13 '18 at 13:07
  • I have little experience with XML - I have to admit. However, if self-repair kicks in your file will likely still be reverted. Try by deleting the main EXE from an elevated command prompt, then launch an advertised shortcut (just launch the main shortcut). A self-repair operation should take place. Then verify if values are correct or reverted. Users can also run repair via `msiexec.exe` command line - which can be invoked from a deployment system. – Stein Åsmul Dec 13 '18 at 13:16
  • That was a great thought. I tested it out and it only self-repaired by replacing the missing file. It seems to leave the config file alone. I'm not too concerned about the users running a repair via msiexec... someone doing that will likely know that they need to provide the transform along with it. – Dewey Vozel Dec 13 '18 at 17:47
  • I forgot to mention that you should check if the config file is in the same or a parent feature of the file you deleted. MSI is very quirky. Sorry, I forgot before. – Stein Åsmul Dec 13 '18 at 17:50
  • Same feature, different component. – Dewey Vozel Dec 13 '18 at 21:06

0 Answers0