This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Property Replacement in XML File Change Problem
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 24, 2009
04:43 PM
Property Replacement in XML File Change Problem
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?
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?
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2009
01:09 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2009
04:05 PM
Michael,
Thanks for the link. I'll give that a try and let you know how it goes.
Thanks for the link. I'll give that a try and let you know how it goes.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2009
05:05 PM
Sadly...it didn't fix it.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 25, 2009
06:13 PM
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...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 26, 2009
10:48 AM
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
Element: root
Attribute (Create, Install): test; Value: foo/[VersionNT]/bar/{0}/quux
yielded
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 26, 2009
05:07 PM
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}
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:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 27, 2009
04:28 PM
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
Element: root
Attribute (Create, Install): test; Value: foo/[VersionNT]/bar/{0}/quux
Element content: foo/[VersionNT]/bar/{0}/quux
yielded