Powershell: Export-CliXml shouldn't require writing to a file

[pcgeek86]

The Export-CliXml command should offer a parameter set that emits a string, instead of writing the result to a file. Right now, it only supports outputting CLIXML to a file via the -Path or -LiteralPath parameters.

Cheers,
Trevor Sullivan

[mklement0]

Given how this distinction is handled in existing cmdlets (e.g., Export-Csv / ConvertTo-Csv), that would probably call for a new cmdlet named ConvertTo-CliXml, plus a matching ConvertFrom-CliXml.

[RichardSiddaway]

Struggling to see the use case for Clixml representation of a an object just in memory. The CliXml cmdlets, as I understand them, are about persisting objects

[pcgeek86]

There are many different places you might want to persist objects. The filesystem is just one place.

[pldmgg]

Just came across a decent use case for this...

Environment variables currently on take strings, so storing a complex object as an environment variable is not really possible. But if Export-Clixml could export a string to an environment variable, then we could relatively easily use Import-Clixml to re-hydrate the object.

[markekraus]

If this followed the convention of CSV, it would actually be better to have a ConvertTo-Clixml cmdlet as well as a ConvertFrom-Clixml One reason I could think of this as useful is to pass the persisting object to things other than files, such as network streams or as body data in HTTP without needing to write to a file first.

[pcgeek86]

Building on top of what @markekraus mentioned, another use case would be sending the CLIXML off to a message queue for processing by a different consumer application. I should not have to write the CLIXML to disk, and then read it again, to accomplish this.

[charlieschmidt]

@powershell/powershell grabbing, if i can?

Progress on this: https://github.com/charlieschmidt/PowerShell/tree/powershell-3898-convertfromto-clixml
I'll get the tests & docs added this weekend and do a proper PR

[Nillth]

As a simple workaround how about this...

`$SerializedString = [System.Management.Automation.PSSerializer]::Serialize($Object)

$BackToObject = [System.Management.Automation.PSSerializer]::Deserialize($SerializedString)`

[mklement0]

It's a _viable_ workaround, but I wouldn't call it _simple_, because this behind-the-scenes type is neither widely known nor easy to remember.

As an aside: Serialize() defaults to depth 1, whereas Export-CliXml defaults to depth 2.

[Shriram0908]

I like to work on this issue. I hope that the cmdlets are still needed.

[vexx32]

I see there was an old PR that never got merged and is now closed... but yeah we can still use this. Go for it! 🙂