自定义PowerShell主机和背部转换PSObject到基本类型 [英] Custom PowerShell Host and Converting PSObject back to base type
问题描述
在托管PowerShell运行时，才有可能一PSObject转换回原来的类型，有些怎么样？
When hosting the PowerShell runtime is it possible to convert a PSObject back into its original type some how?
例如：
我有一个小命令调用writeObject和推动ClassXzy的集合中的管道。当我打电话PowerShell.Invoke从事物的主机端取回PSObjects与BaseObject属性的集合。铸造BaseObject到ClassXyz失败。
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.
有什么办法围绕映射每个属性值到其相应的原始对象？
我假设的PowerShell这是否在某种程度上，你可以通过PSObjects到cmdlet和他们得到转换为参数类型。但如何？
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?
我沿着时间花在撕裂到PS组件与反射器，但还没有真正明确了这是如何发生的法宝。
I spent along time tearing into the PS assemblies with Reflector but haven't really nailed down how this magic happens.
任何想法？
编辑：我忘了一个非常重要的细节。我正在测试针对的PSObject因此是BaseObject型被命名为Deserialized.ClassXyz远程对象。这就是为什么我看到这样奇怪的行为。
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.
推荐答案
基思回答了你所提到的反序列化过程之前，你的问题。
Keith had answered your question before you mentioned the deserialization process.
我怀疑这是可能获得原始对象。我不知道PowerShell使用什么类型的序列化的，但如果你认为简单的XML序列化，那么你就可以知道你可以序列化的属性只有的，没有别的。
您不能序列化它的方法人体的。
你不能序列化所有它的活动的用户（或者在某些情况下，这将是可能的，但我不是这样的.NET专家）。
而且因为类型（如在我的例子）可能不可用（例如，组件是仅在远程计算机present），所有类型的信息将需要被传送。
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.
刚刚尝试这个例子：
$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
您会看到，PowerShell的
You will see, that PowerShell
- 变平的继承层次。
- 在工具只有属性
- ，并因为它知道了
的ToString（）的价值，它可以增加该方法的结果也是如此。但正如你可以看到从返回信息的ToString（）并不能反映最新发生任何变化 - 这是冻结值
- 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 fromToString()doesn't reflect the date change any more - it is frozen value.
我没有看到远程序列之间的差异，序列化到CLIXML（通过导出-CLIXML ）或者接收在职当考虑我上面写的，所以我觉得在这两种情况下是不可能的。
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.
这篇关于自定义PowerShell主机和背部转换PSObject到基本类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
