In Windows PowerShell, using assembly System.Windows.Forms is the parse-time equivalent of Add-Type -AssemblyName System.Windows.Forms; that is, System.Windows.Forms.dll is being looked for in the GAC.

While Add-Type -AssemblyName System.Windows.Forms in PowerShell Core works analogously by looking for the DLL among the ones that ship with PowerShell, using assembly System.Windows.Forms doesn't work:

• Not specifying the .dll extension is not supported at all.
  • In WinPS the absence of .dll seemingly served as the signal to look in the GAC.
• With .dll, but without a full path, the assembly is looked for in / relative to the script's location.

Is this a regression bug or were there design changes?

Note: Even a functioning using assembly statement is not enough if a script tries to subclass types from that assembly (trying to use such types as the base class of a PS custom class definition). However, this is a separate issue - see #3641 (comment).

Steps to reproduce

# WINDOWS ONLY

# Note: This works in WinPS
{ iex 'using assembly System.Windows.Forms' } | Should -Not -Throw

Expected behavior

The test should pass.

Actual behavior

The test fails:

Cannot load assembly 'System.Windows.Forms'

Environment data

PowerShell Core 7.0.0-rc.2