Property Replacement in XML File Change Problem

[ScottVA]

Our Basic MSI installer does not seem to want to play nicely with replacing property names with values when using it to change an XML file with an element that contains curly braces. That's a mouth full. Let me see if I can restate it.

We have a Basic MSI installer. In it, we have defined properties that have their values assigned during the execution of the installer - we have some dialogs that prompt the user for information during the install and it stores that information in a property.

[RANDOMPROP]

It is used in several locations in a format like:

http://[RANDOMPROP]/Stuff/{0}/OtherStuff/FinalStuff


During the installation, data entered for [RANDOMPROP] is displayed in a subsequent dialog (with more stuff around it) and it's displayed properly - granted, it's just a text field. But if I enter "192.168.0.1" then it will display:

http://192.168.0.1/Stuff/{0}/OtherStuff/FinalStuff

If I enter "localhost", it will display:

http://localhost/Stuff/{0}/OtherStuff/FinalStuff


Now, one of the files that gets installed is an XML configuration file. We use the value supplied by the user during the install to replace an element in the XML file - using the XML File Changes section of IS. However, when it writes the updates to the XML file, instead of:

http://192.168.0.1/Stuff/{0}/OtherStuff/FinalStuff

I get:

http://192.168.0.1/Stuff/{0/OtherStuff/FinalStuff}

My right curly brace gets shifted all the way to the end of the element. I'm thinking that IS isn't parsing something correctly but I have been unable to find any documentation to refute or confirm that assumption. Has anyone seen behavior like this or know what I should look at to resolve the problem?

[MichaelU]

If you can, try the experimental version of IsXmlCfg on this other thread (http://community.installshield.com/showthread.php?t=185005). It comes with a handful of caveats, but might handle this correctly.

[ScottVA]

Michael,

Thanks for the link. I'll give that a try and let you know how it goes.

[ScottVA]

Sadly...it didn't fix it.

[RobertDickau]

As a stopgap, what if you create a property called EXPR_WITH_BRACES with value {0}, and use [EXPR_WITH_BRACES] in the XML view? A quick test seems to work at this end...

[MichaelU]

Scott, can you be a bit more specific about your test? I'd like to make sure we've addressed your case, but I can't reproduce the failure. Admittedly I'm testing on development code, but the following created an xml file with an attribute in the root element as I expected.

Element: root
Attribute (Create, Install): test; Value: foo/[VersionNT]/bar/{0}/quux

yielded

[ScottVA]

Robert,

Thanks for the suggestion. I'm going to give that a shot and see how that works out.

Michael,

My organization is creating an installer that has four features in it. All of the features make use of a configuration file - they use the same single configuration file. Depending on the feature, specific elements in the configuration file are updated with user supplied information gathered during the display of the dialogs of the installation.

[Our developers are using {0} in the XML file as a variable to get replaced during run-time of the services they created. (Yes - the developers are not writing the installers, it's fallen to the system integration team, of which I am a member, to write the install packages 🙂 )]

There are multiple entries in the "XML Files Changes", (each pointing to the same XML file - each modifying different sections) that are tied to a respective feature. There are four entries in this section with a couple of the changes tied to multiple features. No XML change is duplicated though.

So:

Feature A - XMLChange1, XMLChange3, XMLChange4
Feature B - XMLChange2, XMLChange3, XMLChange4
Feature C - XMLChange4
Feature D - XMLChange4

XMLDocument - changed by XMLChange1, XMLChange2, XMLChange3, XMLChange4

The problem appears in elements modified by XMLChange2. The settings for the element properties where this problem occurs are:
- Always create this element if it doesn't already exist
- Remove element on uninstall
- Set element content

Of which, the content ID_String is like:

http://[RANDOMPROP]/Foo/Bar/{0}/Kilroy/WasHere

Hope this helps to give you a better idea of our environment. I'll post again once I've had a chance to test Roberts idea and let you know the outcome of assigning a property the value of {0} and using that property in the content string.


Addendum:

My resulting XML looks like:



...
...
http://localhost/Foo/Bar/{0/Kilroy/WasHere}

[MichaelU]

For what little it's worth, I ran a test on our development build that also set the element content and it seemed to work for me. So I'm hopeful the next version can handle this, at least. I'm just surprised that the experimental version posted in the other thread would be any different in this regard. Do you seen any different results if you extract this snippet into a sample project with just the change that is failing, and ensure you're testing on a machine that doesn't have that element in the target file (preferably doesn't have the file at all)?

Element: root
Attribute (Create, Install): test; Value: foo/[VersionNT]/bar/{0}/quux
Element content: foo/[VersionNT]/bar/{0}/quux

yielded

foo/600/bar/{0}/quux