Azure Runbook中PowerShell工作流反序列化XML转变量问题

我之前在Azure Runbook的PowerShell工作流里也碰到过一模一样的问题——工作流返回的反序列化对象确实会让常规的属性访问方式失效，不过有两个靠谱的解决方案：

方法1：用InlineScript包裹常规PowerShell代码 #

PowerShell工作流的自动序列化/反序列化机制是问题根源，而InlineScript块里执行的是标准PowerShell环境，不会对对象做特殊的序列化处理，所以可以直接用你熟悉的代码逻辑：

workflow GB_RB_WF_1 {
    # 如果需要传递工作流参数到InlineScript，要用Using:前缀
    $resourceGroup = "RG1"
    $vmName = "VM1"

    $VMStatus = InlineScript {
        # 这里的环境和常规PowerShell一致，对象不会被反序列化
        $VM = Get-AzureRmVM -ResourceGroupName $Using:resourceGroup -Name $Using:vmName -Status
        $VM.Statuses[1].DisplayStatus
    }

    # 现在可以正常使用$VMStatus变量了
    Write-Output "当前VM状态：$VMStatus"
}

方法2：将反序列化对象重新序列化为标准PSObject #

如果不想用InlineScript，可以把反序列化的对象先转成JSON，再转回标准的PSObject，这样就能按常规方式访问属性：

workflow GB_RB_WF_1 {
    $VM = Get-AzureRmVM -ResourceGroupName RG1 -Name VM1 -Status

    # 把反序列化对象转成JSON（指定足够的Depth避免截断）
    $serializedVM = $VM | ConvertTo-Json -Depth 10
    # 转回标准PSObject
    $normalVM = $serializedVM | ConvertFrom-Json

    # 现在可以正常获取状态了
    $VMStatus = $normalVM.Statuses[1].DisplayStatus
}

为什么会出现这个问题？ #

PowerShell工作流为了支持持久化执行、断点续跑等特性，会自动将所有对象序列化为PowerShell的XML序列化格式，之后再反序列化为Deserialized.xxx类型的对象。这类对象的属性结构虽然和原对象类似，但底层存储方式不同，直接访问可能会出现异常或者取不到值。

内容的提问来源于stack exchange，提问作者warnox