Prof. Powershell

XML Marks the Spot

Use the Export-Clixml cmdlet when capturing XML data that you'll want to use later in a PowerShell session.

• By Jeffery Hicks
• 07/24/2012

In the Windows world the XML format has long been the format of choice for capturing complex data. XML is a big topic that deserves a number of lessons, but I'll save that for later. Today I want to cover a few choices you have in taking PowerShell data and turning it into XML.

The first question I always ask in this situation is, "What do you intend to do with XML data?" If you intend to re-use the XML data in a future PowerShell session, then I have one recommendation. If you need XML that you can use outside of PowerShell, then I recommend a different choice. In either situation, XML is the right choice if you need to capture rich objects complete with nested object properties. The CSV format can't handle this, but XML is perfect for hierarchical data.

If you intend on only using the XML data within a PowerShell session, then the best choice is to use the Export-Clixml cmdlet. You can run any PowerShell expression and as long as it writes objects to the pipeline, export it:

PS C:\> Get-Process | Export-Clixml C:\work\myprocs.xml

This might take a little bit to run because all objects are being serialized. In my case I got a 21MB file:

PS C:\> dir C:\work\myprocs.xml

Directory: C:\work

Mode        LastWriteTime    Length  Name
----        -------------    ------  ----
-a---   5/23/2012 1:56 PM  22215572  myprocs.xml

Sure it is big, but I now have a snapshot of all processes. I can "recreate" those processes by re-importing them into PowerShell:

PS C:\> $importProc=Import-Clixml C:\work\myprocs.xml

The objects even look like process objects:

PS C:\> $importproc

Handles NPM(K)  PM(K)  WS(K) VM(M) CPU(s)   Id ProcessName
------- ------  -----  ----- ----- ------   -- -----------
    196     15  26080  19476    73        6272 audiodg
    121     10   4308   2340    56   0.17 5012 cAudioFilterAgent64
    650     51  35048   8984   241 179.03 2524 cfp
    107     14   5188   1060    88   0.19 6072 CFSwMgr
...

Although technically these are Deserialized.System.Diagnostics.Process objects which means I have no methods, but usually all I want are properties and values anyway.

To use Export-Clixml you must specify a filename. Optionally, you can also limit the hierarchy depth. The default value 2 which means the cmdlet will go down 2 levels. If you have an exceptionally rich object you can capture even more information.

One drawback to this file is that I have always found it problematic to work with outside of PowerShell. For those situations use ConvertTo-XML.

PS C:\> $xml=Get-Process | ConvertTo-Xml
PS C:\> $xml

xml             Objects
---             -------
version="1.0"   Objects

The cmdlet doesn't create a file, it only creates an XML representation of piped in objects. Like Export-Clixml you can also limit the depth with -Depth. You can also use -NoTypeInformation if you plan on using the file outside of PowerShell. Otherwise, the cmdlet adds some helper information so that if you load the xml in a PowerShell session it has some hints as to what the original objects were.

Because $xml is a complete XML document, it can be modified or explored right from here. But to save the results to a file is a little trickier. You can't just pipe the object or cmdlet to Out-File. Instead you need to invoke the object's Save() method.

PS C:\> $xml.Save("c:\work\procs.xml")

I strongly recommend using the complete filename and path. Curiously, this file is only 1.5MB. But I should be able to use this file anywhere, even back in a PowerShell session.

PS C:\> [xml]$impXML=get-content c:\work\procs.xml

Working with this data is beyond what I want to cover today. But now you have a few tools to transform your PowerShell data to XML. Please transform responsibly.