Creating Custom XML from .NET and PowerShell


In my previous article, I walked through piecing together a custom XML file using ConvertTo-Xml. Obviously, this technique works, but it involves a lot of string parsing and manipulation and maybe even some regular expressions. In some ways, I find it to be too “busy.” So let me demonstrate another technique to assemble an XML document from scratch using the .NET Framework.

Before I jump in, I want to head off any comments from readers who are just jumping into the series — if you are intending to save output from a PowerShell expression to XML so that you can re-use it in another PowerShell session, then Export-CliXml is all you need. I covered that in previous articles.

Instead, let’s create an XML file with information pulled from PowerShell that you might need to use outside of PowerShell. You could still bring it back in a PowerShell session, it just requires a few more steps, which I’ll cover in another article. My goal in this article is to create the same type of XML file as I did in the last article. I’m going to get some system information from WMI using Get-CimInstance on a collection of servers.

The XML file will eventually contain this information in a structured format. The first step is to create a blank XML document object. The .NET Framework has a complete XML library under System.XML.  Here’s how to create the document.

This is now just another object, which means you can pipe it to Get-Member to learn more about it.

If you’ve been paying attention, you’ll notice that I keep referring to XML as being hierarchical.  In other words, the document has layers of information. These “layers” are referred to Nodes. Some nodes can be annotated with attributes that provide additional information or context. Within a node you might have one or more elements.

When creating an XML document from scratch, you almost do it from the inside out. You create child and parent “containers” and then add each child to the parent as you move up the hierarchy.  Let me show you.

First, I want to add an XML declaration to the document. This will show the XML version number and encoding.

This object needs to be added to the document.

I thought I would also add a comment to the document, which I’ll define in a here string.

I could use the CreateComment() method from $Doc, save the result to a variable and then append it, or I can do it all in one line.

Here’s what it looks like thus far.

An XML Document
An XML Document (Image Credit: Jeff Hicks)

What’s missing is a root node. I’ll create a node with the name of Computers.

Now I need to go through my data and create the necessary child nodes and elements. My goal is to have a Computer node for each server, so I’ll use a ForEach loop to process my list of servers. The first things I’ll do is create the child node.

For the sake of education, I’m also going to create an attribute called Name, which will have the computername as a value.

Next, I will create a node for operating system information.

Obviously, I need data, so I’ll get the related information from computername as the loop is currently processing.

I’m hoping that even though I’m using some new objects and methods, the syntax is familiar to you. Now we get to change gears a bit.

In the <OperatingSystem></OperatingSystem> node that I’ve defined, I want to create a set of elements based on the properties from my WMI query. I’ll do this by creating an element.

The element can be called whatever you want. In my case, I am using Name and I intend the Caption property from WMI to be the value.

Once created, I need to add it to the parent.

The remaining WMI properties don’t need any transformation. The property name can be the element name so I’ll loop through the properties and repeat the previous steps.

At this point the $osnode is complete and I need to add it to its parent.

The resulting XML will look like this:

XML result
the XML result (Image Credit: Jeff Hicks)

Once you understand the process, doing the same thing for computer system information is almost the same.

Once we get to services, the first few steps are the same.

But, each server has a different set of services. That’s what is in $data. Each item in $data needs to be its own element and I want each WMI property to be the value.

This process will build up the $svcnode variable to contain elements describing each service. Of course, this node also needs to be appended to its parent, and then I need to append the entire computer node to the root.

Almost done. I still need to append the root node to the document itself after processing all the computer names.

Keeping track of parent and child objects is the hardest part of creating an XML document from scratch.

The final step is to save the document.

This looks like a lot of work, and frankly, some of it is. But the more you work with this, the easier it will become. Let me give you the final and complete code that I saved in a script file.

As you look through this code, you’ll notice I’ve used Out-Null in many places. Many of the XML methods will write something to the pipeline. I didn’t want that output, so I’m sending the results to null.

When I run the script, I’ll get a final XML file like this:

The final XML
The final XML (Image Credit: Jeff Hicks)

My intention in this article isn’t to demonstrate how to create an inventory report, but rather how to use the different parts of the XML library from the .NET Framework. Use what I’ve demonstrated here as a starting point for your own scripting projects.

In the next article, we’ll look at how to bring all of this XML data back to life in PowerShell.

Related Topics:

  • PowerShell

    Don't have a login but want to join the conversation? Sign up for a Petri Account