I have a couple of problems using xml file changes under install shield 2008 and would appreciate any help as i am quite new to install shield.
Firstly i have a series of xml documents that are created by install shield using the xml file changes option. Attibutes within the xml file are modified by details user enter into the dialog boxes that are displayed as part of the user interface and other predefined properties, e.g. i use [INSTALLDIR] to add a path. When i perform an install action these work fine and the xml attributes are populated with the correct values. If after an install i do a repair, the attributes are populated with blank values. I have tried setting the xml file change associated components to have a condition of "Not Installed" but the files are still recreated when a repair is done and the attributes are set to blank values.
The second problem i have is that i install a xml file, and then use XML file changes to modify the file. This works fine on an install, but if the install fails and does a rollback the xml file is left behind with attrributes of read only, hidden and system. After this any further install fails, possibly due to the fact that the file is read only and i have to manually delete the left over file before i can attempt a install. Files that are created by the xml file change option do not seem to be effected by this, only the file that i create and then try to modifiy.
For the first part, this could happen to registry and INI changes also, not just XML. MSI properties don't persist after the installation transaction is complete. So when the repair transaction begins if defaults back to blank values since these properties weren't set in the Property table.
What you need to do is implement a `statesaver` pattern. A basic version is an XML System Search to read the XML settings back into the properties so that they can be used to write back out again.
BTW I usually use a couple of properties and conditionalized CA's to enforce a general rule of value precedence:
1) default a certain value 2) retrieve existing value 3) respect override value passed in at the command line.
This means that on first install an existing value is not found so a default is provided and a user can override.
On repair the existing value overrides the default value and the user doesn't get to change it.
On a change or upgrade operation the user gets to override the existing value if they choose.
