views:

459

answers:

2

When hosting the PowerShell runtime is it possible to convert a PSObject back into its original type some how?

For example:

I have a cmdlet that calls WriteObject and pushes a collection of ClassXzy in the pipeline. When I call PowerShell.Invoke from the host end of things I retrieve a collection of PSObjects with a BaseObject property. Casting BaseObject to ClassXyz fails.

Is there any way around mapping each property value to its corresponding original object?
I'm assuming PowerShell does this somehow as you can pass PSObjects to cmdlets and they get translated to the Parameter types. But how?

I spent along time tearing into the PS assemblies with Reflector but haven't really nailed down how this magic happens.

Any ideas?

EDIT: I forgot one very important detail. The PSObject that I'm testing against is a remote object thus the BaseObject type is named Deserialized.ClassXyz. This is why I'm seeing such strange behavior.

+1  A: 

You can access either the BaseObject property on PSObject (which walks each PSObject until it hits the actual base object) or ImmediateBaseObject which just grabs the next object in the chain.

Keith Hill
I forgot something really important. The PSObject is from a remote operation. See my updated question for more detail. Your answer does in fact work for local operations.
Adam Driscoll
PowerShell remoting is using WSMan/SOAP underneath so it doesn't "remote" live objects. What you get back as a "Deserialized.*" object is just a property bag with no connection back to the original object.
Keith Hill
Thanks. The remoting factor changed this question completely!
Adam Driscoll
+1  A: 

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.

stej
Yeah the flaw in my thought process was that I completely forgot about the remoting part! It makes sense that there is no way to have a live object on the other side of the pipe. Thanks for the nice example.
Adam Driscoll