Is upgrading and XML File Changes incompatible?

[Ron_Schaeffer]

I have recently started using XML File Changes to update a config file with a user specified value (via a dialog). I have the basic file change activity working for our installation. However, now that I have another build / version of my installer to implement, whereby it upgrades my prior installation, I am finding the config file from the original installation is retained and not replaced by the new config file - because the config file is considered "modified"!

This upgrading of a prior installed version seems like a pretty necesary issue, yet I haven't been able to find any references to others encountering (or solving) this particular issue.

Am I missing something obvious? Am I doing something wrong?

Thanks for any hints or assistance.

[Reureu]

Hi,

I remember facing a similar issue, but it was in maintenance mode.
Indeed, the XML file changes are applied only when the corresponding component/feature is installed or reinstalled.
This led me to the solution presented in a different thread.

But in the case of the minor upgrade, it seems to work fine, and the solution above is not needed.

So here are a few suggestions:

• You might want to make sure that the feature that contains your XML file is reinstalled when you perform your minor upgrade.
  To do that, log the minor upgrade and then check the value of the REINSTALL property.
  
• Then check if the corresponding feature is really reinstalled, or if the minor upgrade sets it to advertised, which would mean there is another issue.
  
• Finally, use the Upgrade Validation Wizard to validate the minor upgrade. It might reveal some problems you haven't spotted.
  

Regards

[Ron_Schaeffer]

To restate my problem - I have a Config file being delivered by a component in my installer; I have an XML File Change set up on this Config file component to apply an install time revision to the file; I install version 1 on a clean system and it lays down the included file and revises it; I then install version 2 and it does not deliver the new v2 file, nor apply the install time revision.

And the reason that the new v2 file does not get delivered / revised is because the v1 file already exists and is considered to be 'modified':

MSI (s) (24:A0) [11:50:17:292]: File: myfile.config; Won't Overwrite; Won't patch; Existing file is unversioned but modified

The irony is that the v1 file is modified by the installer, but none the less it is modified under Windows Installer rules. 😞

I tried a couple of things to work around this, including delivering the component file to an alternate folder and then using the DuplicateFiles table/action to copy the component file to the 'real' target location. That actually worked in terms of overwriting the v1 file - except that the ISXmlInstall action (which implements the XML File Change) occurs before the DuplicateFiles action; net result: the v2 XML File Change is applied to the existing v1 file on disk, and then the new v2 file is copied over top of the v1 file without XML File Changes. 😞

However, I was able to get the result I wanted by simply setting the Always Overwrite file property of the Config component key file. This basically tells Windows Installer to ignore the existing file modification and overwrite it; plus, as I have the XML File Change associated with the Config file component (not its own separate component, as InstallShield creates by default), the XML File Change also gets done. 🙂

This also works (activities happen) when doing a Repair.

A maintenance mode Modify is as you point out a little different, in that actions only occur if the feature/component state is changed (i.e., from not installed to installed, for example). However, I'm fine with how that functions.

[Reureu]

My idea was to understand why the file was not reinstalled in the first place. Your solution forces the file to be overwritten. It might have other side effects, but if it is ok with your requirements, then that's also fine.