Reading XML files with PowerShell

mystery. Traditionally, IT pros did not need to know anything about XML documents, tags, attributes and namespaces. But with the DevOps movement, infrastructure as code and a big push for configuration management in environments, many administrators are starting to get a taste of XML and what it is used for during their scripting tasks.

Anyone managing Windows systems uses PowerShell. Like many other languages, PowerShell has native support for creating, modifying and reading XML files.  There are a few different ways of reading XML files in PowerShell, but the easiest is to typecast a variable to the type [xml]. 

Typecasting is a term used to describe changing a type of variable from one to another. To do this in PowerShell is simple. PowerShell provides you with built-in XML type accelerator. Type accelerators are a shortcut to transform variables into different types. To transform a variable called $MyVariable you can simply add [xml] to the front of the variable.

[xml]$XmlDocument

This, by itself, does not do much other than create a blank variable. You need to put some XML into that variable. To read an existing XML document, use the Get-Content cmdlet and point it to an XML file. For example, if there is an XML file with several different cars listed, the following command will read that file with PowerShell:

[xml]$XmlDocument = Get-Content -Path C:\Cars.xml

This brings the raw text from the C:\Cars.xm file into the $XmlDocument variable, which is automatically converted to a System.Xml.XmlDocument type of variable.  Once the variable is in this format, we can start reading data inside with PowerShell's familiar dot notation.

Before that, in Figure 1 we look into the C:\Cars.xml file and see it contains different car makes, models and other features.

In Figure 2 is an example of where I'm creating a variable called $XmlDocument, which details the variable type and what is contained in the variable.

Dot notation makes it easy to read the document and explore the XML tree by treating each node as a parent and child. For example, typing the variable will display the output as in Figure 2. This shows you the document element -- the parent of all of the other "child" elements. To dive deeper and check out how many cars are in the document, append the name of the parent element to the variable as in Figure 3.

The example shows three separate Car elements under the parent element Cars. To go even deeper and find out what kind of cars are in this XML document, append the name of the element to the end again as in Figure 4.

Notice in the example above the ft -- auto characters. These are there to squeeze all the properties together so they don't span the console; they are not related to reading the XML document.

Elements or tags are essentially the labels that designate a new item; in this case, cars. However, cars have attributes as well. Cars have a make and model that are XML attributes. When using dot notation, PowerShell doesn't care about this distinction; it shows the elements and the attributes in a table. This makes it easy to navigate the XML document tree, but what if you already know what you want?  If you want to search for a particular type of car, then you wouldn't want to keep typing a dot for every child element.

What if you've got a XML document that's dozens of elements deep? If you need to search the XML document; there are a few options. Since PowerShell converted the documents into objects, you can use the Where-Object cmdlet and filter them as in Figure 5. Many beginners use this approach because it's familiar and it's easier than other methods that may be more powerful but are harder to understand.