Exception when loading: [System.Windows.Markup.XamlReader]::Load($XmlNodeReader)

[HenryHerman]

VSCode Version: 1.41.1 with PowerShell Extension. No Other Extensions are installed
OS Version: Windows 10 - Ver. 1909

Steps to Reproduce:

[void][System.Reflection.Assembly]::LoadWithPartialName('presentationframework')
[xml]$XAML = $inputXML
$reader=(New-Object System.Xml.XmlNodeReader $xaml)
$Form=[System.Windows.Markup.XamlReader]::Load($reader)

When running Powershell Core 7 RC2 in VSC: This Exception is thrown when loading: [System.Windows.Markup.XamlReader]::Load($reader): "Exception calling "Load" with "1" argument(s): 'The invocation of the constructor on type 'System.Windows.Window' that matches the specified binding constraints threw an exception.'"

It is the same issue regardless how I run the Code - by the RUN button or from the command line in the terminal window by calling the script file

When running the exact the same script file from command line in Powershell Core 7 RC2 without VSC involved, then no Exception is thrown and the script works perfect.

There is no issue in VSC when running the script in Powershell 5.1.

Powershell Extension is the only one installed. When i disable PowerShell Extension I am able to run the script from command line in the terminal window.

[HenryHerman]

Script attached Get-FixedDiskv3.txt

[rjmholt]

I just tried this now using the initial repro snippet and I hit a similar exception, but because $inputXml was $null. Following your script, this worked for me in 7.0.0-rc.2 in the Integrated Console:

If you're hitting this consistently, could you post the results of Get-Error.

I should also mention that the [System.Reflection.Assembly]::LoadWithPartialName API has been deprecated for some time in both .NET Core and .NET Framework. But particularly in .NET Core, there is no GAC, meaning that assembly is coming from somewhere else. Ideally in PS 5.1 and below you should load it with a full name, and in PS 6 and above you should load it from a file (I suspect the one you're getting is the one distributed with PowerShell in $PSHome).

[HenryHerman]

github-2459.txt HI Robert Thanks for your comments :-) I get the error consistently. The result from get-error is attached

[rjmholt]

I see this in the error:

The calling thread must be STA, because many UI components require this.

Can you post the result of:

[System.Threading.Thread]::CurrentThread.ApartmentState

This suggests that your PowerShell might be in MTA apartment state for some reason (running the same PowerShell version, mine is not). We specifically set the runspace ApartmentState to STA, so this is quite mysterious.

[HenryHerman]

Before I continue could you please explain to me, why the script works perfect in PowerShell 7, when I disable the PowerShell Extension in VSC?

[rjmholt]

Wait, writing a response here I just had an idea. I'm suspecting that the issue you're having is something that's only present in the stable extension. If you can, try powershell-preview and see if the issue is resolved. That will become stable this month.

Before I continue could you please explain to me, why the script works perfect in PowerShell 7, when I disable the PowerShell Extension in VSC?

Of course! The PowerShell extension gets almost all of its functionality from a PowerShell process behind the scenes. But all of the interaction that looks like PowerShell in the extension is actually running in quite a different way due to the constraints of PowerShell's architecture.

Completions in PowerShell come from the current runspace and are entirely contextual, so most of the complexity in the extension is devoted to an architecture where we:

• Use the PowerShell installed on your machine (rather than forcing you to use a particular PowerShell version)
• Load ourselves into it
• Take over the pipeline thread
• Present a prompt over the top of it
• But also use it to run completions, debugging, code analysis, reference tracking, etc.

To do this, we have to carefully shuttle things to and from the pipeline thread. This involves careful management of the runtime state of the process, including the runspaces. So the PowerShell that you're running in the Integrated Console, in order to be integrated, is quietly running some other threads to give you PowerShell extension features.

BUT, as I realised above, if you're running the stable extension you're probably missing out on a lot of small changes we've made to the extension to basically get out of the way of scripts.

[HenryHerman]

The Preview version of the extension has the same version number 2020.1.0, so previous I did not think it was worth trying to use the preview version, but by your request I tried and my problems was solve. Thanks for your assistance :-)