Error loading the wrong assembly with not elegant workaround

[JaimePalazuelosB]

Hi,

I am using this module for Azure Policies with Automanage. This is DSC based, and it runs both PowerShell and any modules on the policy's package in an isolated folder. Therefore, even if the machine does not have PowerShell 6 installed, it runs it using this version.

The module is working fine almost on every machine, but there are some where I am having an error in this section:

$parserType = $yamlDotNetAssembly.GetType("YamlDotNet.Core.Parser")
$parser = $parserType::new($stringReader)

These machines are Windows 2019 Datacenter, but it is identifying them as Core, so it is loading the "netstandard2.1" assembly instead of "net47", causing an error "Get-Serializer: You cannot call a method on a null-valued expression".

Running the same code using PowerShell 5.1 installed on the machine does not cause any error, I guess because it does not detect the machine as Core.

I have temporarily implemente the following workaround:

function Invoke-LoadAssemblyOnError {
    $libDir = Join-Path $here "lib"
    $assemblies = @{
        "core"  = Join-Path $libDir "netstandard2.1"
        "net47" = Join-Path $libDir "net47"
    }

    return (Invoke-LoadFile -assemblyPath $assemblies["net47"])
}


function Get-YamlDocuments {
    [CmdletBinding()]
    Param(
        [Parameter(Mandatory = $true, ValueFromPipeline = $true)]
        [string]$Yaml,
        [switch]$UseMergingParser = $false
    )
    PROCESS {
        $stringReader = New-Object System.IO.StringReader($Yaml)
        try {
            $parserType = $yamlDotNetAssembly.GetType("YamlDotNet.Core.Parser")
            $parser = $parserType::new($stringReader)
        }
        catch {
            $assemblies = Invoke-LoadAssemblyOnError

            $yamlDotNetAssembly = $assemblies["yaml"]
            $stringQuotedAssembly = $assemblies["quoted"]

            $parserType = $yamlDotNetAssembly.GetType("YamlDotNet.Core.Parser")
            $parser = $parserType::new($stringReader)
        }

        if ($UseMergingParser) {
            $parserType = $yamlDotNetAssembly.GetType("YamlDotNet.Core.MergingParser")
            $parser = $parserType::new($parser)
        }

        $yamlStream = $yamlDotNetAssembly.GetType("YamlDotNet.RepresentationModel.YamlStream")::new()
        $yamlStream.Load($parser)

        $stringReader.Close()

        return $yamlStream
    }
}

It is not an elegant solution, so I would rather to have an official and better resolution.

Thanks in advance.

Jaime

[gabriel-samfira]

This is interesting. It's identifying them as Core because you're probably running pwsh.exe (powershell Core - portable, cross platform, built on .Net Core) instead of powershell.exe (Windows Powershell built on .Net framework).

So if you're running pwsh, it will most likely be detected as Core, which is fine. Loading the netstandard version if the assembly should be fine. I am curious why it fails. Can you provide some steps on how to replicate the conditions on a Windows VM? I don't need the actual DSC. I am curious about the powershell binaries included, though. Are they publicly accessible somewhere?

[JaimePalazuelosB]

This is interesting. It's identifying them as Core because you're probably running pwsh.exe (powershell Core - portable, cross platform, built on .Net Core) instead of powershell.exe (Windows Powershell built on .Net framework).

So if you're running pwsh, it will most likely be detected as Core, which is fine. Loading the netstandard version if the assembly should be fine. I am curious why it fails. Can you provide some steps on how to replicate the conditions on a Windows VM? I don't need the actual DSC. I am curious about the powershell binaries included, though. Are they publicly accessible somewhere?

Yes, you are correct. I am using this code in an Azure Policy, using Automanage, formerly known as Guest Configuration. Azure installs a package on the VM, in a folder C:\Packages\GuestConfiguration, that contains a folder named GC where that pwsh.exe is located. The bins on that folder run kind on a containeraized way, not a proper container, but like running on an isolated mode on the VM. The funny thing is that, this works fine on a long list of VMs, but it fails just on a few of them. I do not know if this is related with some configuration in the specific VMs where it fails, but I cannot find a pattern. With the workaround it works, the only thing I am doing is that if it fails with the netsatandard, it tries with the net47, and in this case it works.

In this case the problem raised on VMs deployed with Windows Datacenter 2019, if you have Azure you can install the Guest Configuration extension, and you will have with this combination the exact same binaries. You do not need to worry about creating a policy, just go to that folder and you will have the binaries you are looking for, you should be able to replicate the issue with any yaml file.

I am going on holidays, so if I do not reply to any message please do not think I am ignoring them, I will just try to disconnect.

Thanks!!

[gabriel-samfira]

I am going on holidays, so if I do not reply to any message please do not think I am ignoring them, I will just try to disconnect.

I strongly encourage you completely ignore any emails from me while on holiday. Enjoy!

I will try to find some time to have a look at this. See what's happening.