JSON Serialization Options

            April 2, 2024

        JSON Serialization Options

            In the previous article in this series, we explored PowerShell serialization. This is the process of converting an object into a format that can be stored or transmitted, typically via a file. PowerShell does this automatically in remoting situation. You can obtain the best fidelity by using the `Export-CliXml` and `Import-CliXml` cmdlets. These cmdlets serialize and deserialize objects to and from XML files. This is a great way to store objects in a file and retrieve them later. The format includes key type information, so you can be sure that the object will be reconstituted correctly with minimal effort.

Another option you might consider is JSON. This is a lighter-weight format that is more human-readable than XML. PowerShell has built-in cmdlets to convert objects to and from JSON. The `ConvertTo-Json` cmdlet converts an object to a JSON string, and the `ConvertFrom-Json` cmdlet converts a JSON string back to an object. In order to know when to use JSON for serialization over other alternatives, you need to understand the limitations.

Let's start with a relatively simple object.

$o = Get-Service bits | Select Name,Status,DisplayName,StartType,

@{Name="ComputerName";Expression={$env:COMPUTERNAME}},

@{Name="Date";Expression={(Get-Date)}}

It is easy enough to convert this object to JSON. Although this presents the first challenge. The `ConvertTo-Json` cmdlet behaves differently between Windows PowerShell and PowerShell 7. This can have an effect on the import using `ConvertFrom-Json`. You have to take into account how you will be using the JSON files. Will you be sharing them between different versions of PowerShell? What is your expectation when you deserialize the JSON file?

Here's the Windows PowerShell conversion:

PS C:\> $o | ConvertTo-Json

{

    "Name":  "bits",

    "Status":  4,

    "DisplayName":  "Background Intelligent Transfer Service",

    "StartType":  2,

    "ComputerName":  "PROSPERO",

    "Date":  {

                 "value":  "\/Date(1712066367115)\/",

                 "DisplayHint":  2,

                 "DateTime":  "Tuesday, April 2, 2024 9:59:27 AM"

             }

}

Notice the difference with PowerShell 7:

PS C:\> $o | ConvertTo-Json

{

  "Name": "bits",

  "Status": 4,

  "DisplayName": "Background Intelligent Transfer Service",

  "StartType": 2,

  "ComputerName": "PROSPERO",

  "Date": "2024-04-02T10:00:04.2033318-04:00"

}

You can see the challenges.

Get a premium subscription for full article and archive access

In the previous article in this series, we explored PowerShell serialization. This is the process of converting an object into a format that can be stored or transmitted, typically via a file. PowerShell does this automatically in remoting situation. You can obtain the best fidelity by using the Export-CliXml and Import-CliXml cmdlets. These cmdlets serialize and deserialize objects to and from XML files. This is a great way to store objects in a file and retrieve them later. The format includes key type information, so you can be sure that the object will be reconstituted correctly with minimal effort.
Another option you might consider is JSON. This is a lighter-weight format that is more human-readable than XML. PowerShell has built-in cmdlets to convert objects to and from JSON. The ConvertTo-Json cmdlet converts an object to a JSON string, and the ConvertFrom-Json cmdlet converts a JSON string back to an object. In order to know when to use JSON for serialization over other alternatives, you need to understand the limitations.
Let's start with a relatively simple object.

                Want to read the full issue?

Behind the PowerShell Pipeline

JSON Serialization Options