Keith had answered your question before you mentioned the deserialization process.
As for serialization/deserialization
I doubt it is possible to get original object. I don't know what type of serialization PowerShell uses, but if you consider simple Xml serialization, then you can realize that you can serialize only properties and nothing else.
You can't serialize bodys of its methods.
You can't serialize all it's event's subscribers (or maybe in some cases it would be possible but I'm not such a .NET expert).
And because the type (as in my example) may not be available (e.g. the assembly is present only on the remote computer), all the type information would need to be transmitted.
It is not only about the type, but about all the inheritance hierarchy and interfaces the object implements. They would be serialized somehow as well.
Just try this example:
$deserialized = Start-Job {
Add-Type -TypeDefinition @"
public class Parent {
public override string ToString() { return "overriden parent"; }
public int IntParent { get { return 1; } }
}
public class TestClass : Parent
{
public string GString() { return "this is a test string"; }
public override string ToString() { return "overriden tostring" + System.DateTime.Now.ToString(); }
public int IntProp { get { return 3451; } }
}
"@
New-Object TestClass
} | Wait-Job | Receive-Job
$deserialized.ToString()
$deserialized | gm -for
You will see, that PowerShell
- flattens the inheritance hierarchy.
- 'implements' only the properties
- and because it knows the value of
ToString()
, it can add the result of the method as well. But as you can see the information returned from ToString()
doesn't reflect the date change any more - it is frozen value.
I don't see any difference between serialization for remoting, serialization to clixml (via Export-CliXml
) or when Receive-Job
when considering what I've written above, so I think in both cases it is impossible.