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! 🙂

[foxx]

First of all, thanks to everyone for getting this fixed.

Are there any indications on which release this might land in?

It's a drop in the ocean of the 3.2k open issues, but would be nice to get this issue closed out :)

[doctordns]

So far as I can tell, this PR has not been merged. I can't see any trace of it in either 7.4 preview 3 or a recent daily build.

Are there folks that want to take this on and complete the PR? If not, we should close this.

[ImportTaste]

So far as I can tell, this PR has not been merged. I can't see any trace of it in either 7.4 preview 3 or a recent daily build.

Are there folks that want to take this on and complete the PR? If not, we should close this.

@Shriram0908 disappeared right before the finish line, it seems. 😕

[ArmaanMcleod]

So far as I can tell, this PR has not been merged. I can't see any trace of it in either 7.4 preview 3 or a recent daily build.

Are there folks that want to take this on and complete the PR? If not, we should close this.

@doctordns I've created a new PR which should address this. Will wait for feedback and hopefully get this one merged since I needed this recently and would be great to have these cmdlets in 7.4.