WiX XmlConfig: Purpose for nesting XmlConfig in XmlConfig

Question

What is the purpose and/or gain (other than increased readability for creating/deleting attributes) to nesting an XmlConfig element in another XmlConfig element?

Example of what I'm referring to (I'm using WiX 3.6):

<util:XmlConfig ...>
    <util:XmlConfig ... />
</util:XmlConfig>

Answer 1

The short answer: the only purpose of the option to have nested <util:XmlConfig> elements is to be able to add/remove attributes to/from the newly created elements in a more readable way. So, this is basically what you assumed.

Consider the following initial XML file:

<?xml version="1.0" encoding="utf-8"?>
<cars>
  <car name="ford" type="minivan"/>
  <car name="toyota" type="sedan"/>
  <motos>
    <moto name="honda" model="shadow" type="cruiser" />
  </motos>
</cars>

In order to add another <moto> to it, the following WiX snippet can be used:

<util:XmlConfig Id="elem1" Action="create" ElementPath="cars/motos" File="$(var.XmlFilePath)" Node="element" On="install" Name="moto">
  <util:XmlConfig Id="elem11" ElementId="elem1" Name="name" Value="yamaha" File="$(var.XmlFilePath)" />
  <util:XmlConfig Id="elem12" ElementId="elem1" Name="type" Value="chopper" File="$(var.XmlFilePath)" />
</util:XmlConfig>

As a result, the XML file ends up as follows:

<?xml version="1.0" encoding="utf-8"?>
<cars>
  <car name="ford" type="minivan"/>
  <car name="toyota" type="sedan"/>
  <motos>
    <moto name="honda" model="shadow" type="cruiser" />
    <moto name="yamaha" type="chopper" />
  </motos>
</cars>

Couple of things to note here:

• the Action attribute can't be defined in inner XmlConfig elements, and that's logical - it is the same as the one of the parent element
• the Node attribute can't be defined as well, because only attributes are allowed
• the weird thing is that you have to specify File attribute each time - seems to be a design issue here
• the ElementId attribute should point to the parent element you are adding the attributes to, and that's also strange as it could also be "guessed" from the nested code

Anyway, if you do want to create an XML subtree structure, the elements which end up as nested elements in resulting XML are made by XmlConfig elements placed on a same level. So, the following snippet:

<util:XmlConfig Id="elem1" Action="create" ElementPath="cars/motos" File="$(var.XmlFilePath)" Node="element" On="install" Name="moto" Sequence="1">
  <util:XmlConfig Id="elem11" ElementId="elem1" Name="name" Value="yamaha" File="$(var.XmlFilePath)" />
  <util:XmlConfig Id="elem12" ElementId="elem1" Name="type" Value="chopper" File="$(var.XmlFilePath)" />
</util:XmlConfig>
<util:XmlConfig Id="elem2" Action="create" ElementPath="cars/motos/moto[\[]@name='yamaha'[\]]" File="$(var.XmlFilePath)" Node="element" On="install" Name="extra" Sequence="2">
  <util:XmlConfig Id="elem21" ElementId="elem2" File="$(var.XmlFilePath)" Name="bags" Value="leather" />
</util:XmlConfig>

will transform the XML as follows:

<?xml version="1.0" encoding="utf-8"?>
<cars>
  <car name="ford" type="minivan"/>
  <car name="toyota" type="sedan"/>
  <motos>
    <moto name="honda" model="shadow" type="cruiser"/>
    <moto name="yamaha" type="chopper">
      <extra bags="leather"/>
    </moto>
  </motos>
</cars>

Pay attention to the following:

• the XmlConfig elements are placed on the same level, although they result in a nested elements in the resulting XML
• the Sequence attribute is important, in case you add an attribute or a child to the element, which is also being created

Hope this makes more sense now. Sorry for the wrong answer given initially.