How to check if ini file exists with Wix Toolset

Question

I have an .ini file with configuration. I need to check if it exists in new installation to avoid creating it again. Besides if the new .ini have new fields add to the existing file.

Answer 1

Don't install an ini file as a file, but convert the entries into IniFile Table entries. This allows all ini file changes to be treated as "atomic change units" that allows proper merging and rollback via built-in MSI mechanism. You avoid all custom action complexity.

As Chris points out in his major upgrade comment: do things the right way in Wix / MSI and you avoid a lot of problems that start to pop up when requirements change or updates get complicated. IniFile updates implemented the right way are robust and simple to deal with.

In Wix you use the IniFile Element to achieve this. All merge capabilities, rollback support and advanced ini file handling comes along for free. All you need to do is to define what needs to be added or modified in the ini file during your installation. It will also be created if it is not there in the first place.

Using the IniFile element may look harder than it is. Here is a sample. You can also have a look at the well known Wix tutorial here.

All MSI-experts keep repeating this advice: never use a custom action to change a system if there are equivalent built-in MSI constructs.

Answer 2

Set NeverOverwrite="yes" on the .ini file's component and then handle the update via a custom action.

Edit: Generally it is much better to use the IniFile table as explained in my answer since you get rollback and merge capabilities. However, some people prefer the INI file installed as a file to allow easy modification of the file from outside the MSI file. Though not preferred, this does allow people to "hotfix" the INI file directly on the installation media location. Teams can use this to have the installer pick up the latest INI from development. There are technical problems with this that can be handled via a custom action (most significantly file replacement issues on install). It is also possible that an INI file can feature non-standard elements and formatting that doesn't fit in the IniFile table (rare, but possible - people with sense then use a different file extension than ini). As already explained, I would strongly advice against updating INI files via your own custom action, unless you are doing something very special - that's actually needed. It is complicated to implement and to get right.

Answer 3

I would suggest having 2 INI files. One that the installer owns and one that the application / user owns. The installer can always overwrite it's INI file and never worry about stomping on user data.