XML File Changes not to be executed during maintenance

[Ron_Schaeffer]

Is it possible to configure the XML File Changes activity to only occur during initial installation, not during maintenance activities such as Maintenance (feature selection), Repair and patch application?

My development team has the installer delivering a config file which contains a entry key of "xxxxx0"; at install time the installer asks for some values (i.e., server name and port) with which it updates this entry - everything is fine with this.

However, there is an application maintenance utility which allows the customer to later manipulate this config file, such that there may be multiple "xxxxx" entry keys, such as "xxxxx1", "xxxxx2", etc.; additionally it is valid from an application viewpoint for the "xxxxx0" entry to actually be removed. [Remember - I didn't design or write this - I am just the messenger 🙂 ] Now, when we apply a patch and the config file no longer contains the "xxxxx0" entry key, the XML File Change activity recreates it with installer defined default values - which is invalid (i.e, it may create a duplicate value which is already used in a different entry key; the installer defined default values can be invalid in this customer scenario). If the key already exists, everything is okay because it is rewritten with its existing values - because the installer does a look-up of this key and retrieves the necessary values as its run-time 'defaults'.

Note that I have already thought of unchecking the element attribute 'Always create this element if it does not already exist' and currently this is the only way I see of doing this - though it isn't exactly what I'm looking for (because I can still face an issue when running a new install which will upgrade a prior version - in that case the config file will already exist and may not have an "xxxxx0" entry - the installer will ask for values from the user but then not write them).

Also note that I have considered putting a condition on the component associated with this XML File Change (i.e., Not Installed) - but I think that will simply cause the "xxxxx0" entry to be removed if it exists (because the condition will cause the component to be uninstalled).

So, is there some way to disallow the XML File Change activity during maintenance type activities? Or some other way of dealing with this that I have overlooked?

Thanks in advance.

[MichaelU]

Generally we recommend doing some sort of AppSearch activity to repopulate the same properties you had in your initial install, so that maintenance operations would write the same information back to the same file.

However, as this is not always practical, the direct answer to your question is yes: right click the custom actions root node, and select Show All Custom Actions. Then you can find InstallShield's XML actions and change their conditions to prevent them from running. Be careful doing this: choose your replacement conditions judiciously, and test the results in the various maintenance (including patch, upgrade and uninstall) scenarios you may need to support in the future.

[Ron_Schaeffer]

Thanks Michael.

In regards the AppSearch activity to repopulate the same properties - I'm already doing that, the issue is that the config file has changed since the original install and now the AppSearch key (e.g., "xxxxx0") is no longer there.

In regards conditionalizing InstallShield's ISXml CAs - good thought, I hadn't thought of that; and that could work, once I figure out the conditions for each of the various ISXml CAs, and as long as this is the only XML update I am doing in this installer (this problem is specific to this one update - not a generic issue with any other XML updates). However, I admit to some trepidation about modifying the built-in aspects of these installers - I'm concerned about future IS product upgrades, and the fact that we might use this installer (with its customization) as a prototype for some other installer, and thereby propagate this custom logic where it is unintended (I'm really risk adverse 🙂 ).

At this point, I'm thinking more and more that unchecking the element attribute 'Always create this element if it does not already exist' is the way I'll go (unless there is some overriding reason not to ...).

Thanks