I have a WiX installer for an application, and it installs both an INI file, and an XML file (both of which are configuration files).
So having them as part of the install is not a great move, so now I've modified the install so that the files installed are DEFAULT files (.default), and I run a element to copy to the real configuration file. The problem here, is that then the file is removed during an uninstall/upgrade.
So I have a custom action that copies the default files to 'real' config files, which means they will be left when uninstalling. This only works AFTER (since before that, the file hasn't been laid down yet)
The problem is, there are wizard dialog pages and silent install parameters that the user could use to config the application during install. And when or run, the files haven't been copied yet!
The ideal fresh install sequence would be:
- default config INI/XML files are laid down
- 'real' config files are copied from originals
- INI values and XML modifications on UI/silent are made to 'real' config files
and then upgrade
- new default config INI/XML files are laid down
- INI values and XML modifications are made to 'real' config files
and uninstall
- application files and default files removed
- 'real' INI/XML config files left alone, suppressing INI/XML rollback
What should be the pattern for this?
I'm trying to make the scenario as simple to describe as possible. I feel like a design pattern exists/should exist for this.
What is the preferred pattern for allowing configuration parameters in an install, to be written to a file NOT (strictly) part of the install?
This is a very broad subject but in general my best practice approach is that the installer only lays down default values and always overwrites the files. Then override files are used to provide customizations and the application loads in that order. The installer doesn't know about these files so it never touches them. The application has to be designed to do this and in some cases this isn't possible (web.config as an example). In those cases you have to go through the extra work of loading the customizations you care about, overwriting the file and then reapplying them.
The heart of this problem is that INI and XML files are potentially infinite repositories of data and that the simple "overwrite or not overwrite" servicing rules of MSI just don't work. You eventually get into an unsolvable merge problem. It's best to have 1 file the installer "owns" and always overwrites and one or more other files (layers) that the user or application owns that the installer doesn't know anything about and never modifies then let the application merge the data together to produce the final truth.
Look up my contact info if you'd like to have a more detailed discussion or explanations of why. I'm always willing to discuss design issues without any obligation.