It is impossible to create a Windows Forms class without loading the assembly before parsing the file containing the class

[Bratman117]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

1. Create a simple Windows Forms class in a .ps1 :

using namespace System.Windows.Forms
Add-Type -Assembly System.Windows.Forms

class MyForm : Form {
    MyForm() {
        [Application]::EnableVisualStyles()
        
        $this.Text = 'My Form'
        $this.Size = New-Object System.Drawing.Size(300, 200)
        $this.StartPosition = 'CenterScreen'
    }
}

$myForm = [MyForm]::new()
$myForm.ShowDialog()

2. Try to run it :
   PS> .\myform.ps1

Expected behavior

Empty form opens up

Actual behavior

PS> .\myform.ps1
ParserError: C:\myform.ps1:5
Line |
   5 |  class MyForm : Form {
     |                 ~~~~
     | Unable to find type [Form].

Note that this class works correctly if i instead do this :

PS> Add-Type -Assembly System.Windows.Forms
PS> .\myform.ps1

Removing "using namespace" and specifying "System.Windows.Forms" on each type does not change anything to this behavior, nor does adding a "using assembly" statement (which is supposedly made for this if i understand the documentation about it correctly).

using assembly 'C:\Program Files\PowerShell\7\System.Windows.Forms.dll'
Add-Type -Assembly System.Windows.Forms

class MyForm : System.Windows.Forms.Form {
    MyForm() {
        [System.Windows.Forms.Application]::EnableVisualStyles()
        
        $this.Text = 'My Form'
        $this.Size = New-Object System.Drawing.Size(300, 200)
        $this.StartPosition = 'CenterScreen'
    }
}

$myForm = [MyForm]::new()
$myForm.ShowDialog()

PS> .\myform.ps1
ParserError: C:\myform.ps1:4
Line |
   4 |  class MyForm : System.Windows.Forms.Form {
     |                 ~~~~~~~~~~~~~~~~~~~~~~~~~
     | Unable to find type [System.Windows.Forms.Form].

Error details

Exception             :
    Type        : System.Management.Automation.ParseException
    Errors      :
        Extent  : Form
        ErrorId : TypeNotFound
        Message : Unable to find type [Form].

        Extent  : Application
        ErrorId : TypeNotFound
        Message : Unable to find type [Application].
    Message     : At C:\myform.ps1:5 char:16
                  + class MyForm : Form {
                  +                ~~~~
                  Unable to find type [Form].

                  At C:\myform.ps1:7 char:10
                  +         [Application]::EnableVisualStyles()
                  +          ~~~~~~~~~~~
                  Unable to find type [Application].
    ErrorRecord :
        Exception             :
            Type    : System.Management.Automation.ParentContainsErrorRecordException
            Message : At C:\myform.ps1:5 char:16
                      + class MyForm : Form {
                      +                ~~~~
                      Unable to find type [Form].

                      At C:\myform.ps1:7 char:10
                      +         [Application]::EnableVisualStyles()
                      +          ~~~~~~~~~~~
                      Unable to find type [Application].
            HResult : -2146233087
        CategoryInfo          : ParserError: (:) [], ParentContainsErrorRecordException
        FullyQualifiedErrorId : TypeNotFound
        InvocationInfo        :
            ScriptLineNumber : 5
            OffsetInLine     : 16
            HistoryId        : 2
            ScriptName       : C:\myform.ps1
            Line             : class MyForm : Form {

            Statement        : Form
            PositionMessage  : At C:\myform.ps1:5 char:16
                               + class MyForm : Form {
                               +                ~~~~
            PSScriptRoot     : C:\
            PSCommandPath    : C:\myform.ps1
            CommandOrigin    : Internal
        ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1
    TargetSite  :
        Name          : Create
        DeclaringType : scriptblock
        MemberType    : Method
        Module        : System.Management.Automation.dll
    Data        : System.Collections.ListDictionaryInternal
    Source      : System.Management.Automation
    HResult     : -2146233087
    StackTrace  :
   at System.Management.Automation.ScriptBlock.Create(Parser parser, String fileName, String fileContents)
   at System.Management.Automation.ExternalScriptInfo.ParseScriptContents(Parser parser, String fileName, String
fileContents, Nullable`1 definingLanguageMode)
   at System.Management.Automation.ExternalScriptInfo.get_ScriptBlock()
   at System.Management.Automation.CommandDiscovery.CreateCommandProcessorForScript(ExternalScriptInfo scriptInfo,
ExecutionContext context, Boolean useNewScope, SessionStateInternal sessionState)
   at System.Management.Automation.CommandDiscovery.LookupCommandProcessor(CommandInfo commandInfo, CommandOrigin
commandOrigin, Nullable`1 useLocalScope, SessionStateInternal sessionState)
   at System.Management.Automation.ExecutionContext.CreateCommand(String command, Boolean dotSource)
   at System.Management.Automation.PipelineOps.AddCommand(PipelineProcessor pipe, CommandParameterInternal[]
commandElements, CommandBaseAst commandBaseAst, CommandRedirection[] redirections, ExecutionContext context)
   at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput,
CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][]
commandRedirections, FunctionContext funcContext)
   at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
   at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
CategoryInfo          : ParserError: (:) [], ParseException
FullyQualifiedErrorId : TypeNotFound
InvocationInfo        :
    ScriptLineNumber : 5
    OffsetInLine     : 16
    HistoryId        : 2
    ScriptName       : C:\myform.ps1
    Line             : class MyForm : Form {

    Statement        : Form
    PositionMessage  : At C:\myform.ps1:5 char:16
                       + class MyForm : Form {
                       +                ~~~~
    PSScriptRoot     : C:\
    PSCommandPath    : C:\myform.ps1
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1

Environment data

PSVersion                      7.4.1
PSEdition                      Core
GitCommitId                    7.4.1
OS                             Microsoft Windows 10.0.23619
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[IISResetMe]

This is expected behavior - type definitions and using ... directives in PowerShell source code are parsed and compiled ahead of script execution, and therefore prior to the execution of Add-Type -Assembly System.Windows.Forms.

The solution to this specific scenario is indeed to use a using assembly directive - but instead of a path to an assembly file you want to specify the assembly name along and then let the runtime take care of resolving it for you:

using assembly System.Windows.Forms
using namespace System.Windows.Forms

class MyForm : Form {
    MyForm() {
        [Application]::EnableVisualStyles()
        
        $this.Text = 'My Form'
        $this.Size = New-Object System.Drawing.Size(300, 200)
        $this.StartPosition = 'CenterScreen'
    }
}

$myForm = [MyForm]::new()
$myForm.ShowDialog()

It will have the same effect as Add-Type -Assembly System.Windows.Forms, but since the using directive is parsed and applied by the time the class is compiled you'll no longer see the type resolution error.

---

For more advanced scenarios: leverage the module manifest schema.

If you want to reference a specific DLL on disk (eg. one not discoverable in the GAC), my recommendation would be to declare the assembly file a required assembly in your module manifest - this way the assembly will be loaded into the runtime on module import and available by the the class is compiled.

If you must use Add-Type for whatever reason, you can similarly invoke it in one of your module's ScriptsToProcess or place the call in a separate module file that you can then reference either as a dependent module or through a using module statement

[Bratman117]

@IISResetMe As specified in my longer explanation in Actual behavior, "using assembly" does not change anything to the problem, either by putting the absolute path or, like you just the name.

Absolute path (using assembly 'C:\Program Files\PowerShell\7\System.Windows.Forms.dll') :

PS> .\myform.ps1
ParserError: C:\myform.ps1:4
Line |
   4 |  class MyForm : System.Windows.Forms.Form {
     |                 ~~~~~~~~~~~~~~~~~~~~~~~~~
     | Unable to find type [System.Windows.Forms.Form].

Just the name (using assembly System.Windows.Forms) :

PS> .\myform.ps1
ParserError: C:\myform.ps1:1
Line |
   1 |  using assembly System.Windows.Forms
     |                 ~~~~~~~~~~~~~~~~~~~~
     | Cannot load assembly 'System.Windows.Forms'.

---

While I could leverage the manifest schema, this seems like overengineering for such a problem. Doing my form in C# then using Add-Type would also solve the issue (and also give me better classes), but I feel like this should work 'out of the box' and that, if I understand it correctly, "using assembly" is not working as it is described in Microsoft's documentation.

[237dmitry]

Remove spaces around :

using assembly "C:\Program Files\PowerShell\7\System.Windows.Forms.dll"
using namespace System.Windows.Forms

class MyForm:Form {
....

[Bratman117]

@237dmitry This does not seem to work for me.

PS> .\myform.ps1
ParserError: C:\myform.ps1:4
Line |
   4 |  class MyForm:Form {
     |               ~~~~
     | Unable to find type [Form].

I should mention that this issue is exactly the same in Windows PowerShell 5.1

[237dmitry]

Sorry, apparently while I was testing the assembly was loaded in advance.

[mklement0]

To add to @IISResetMe's explanation of the problem with Add-Type:

It is unfortunate that using assembly System.Windows.Forms doesn't work in PowerShell Core (it works fine in Windows PowerShell); this bug was reported in 2020:

• using assembly statement cannot be used to load well-known assemblies #11856

However, even if it did it wouldn't solve your problem, because - unlike what the documentation currently states - a using assembly statement currently does not load the assembly's types at parse time, which would be the prerequisite to make your scenario work (given that class definitions are also processed at parse time and that all types referenced in them must already be loaded at that point).

The - long-standing - plan is to eventually implement parse-time type loading for using assembly, and there are specific pointers here, but no one has stepped up to implement it yet.

The problem is also explicitly described in:

• using assembly is processed at compile time rather than parse time #18482

This StackOverflow answer summarizes the available workarounds.

Note that using a separate module via using module that loads assemblies via a RequiredAssemblies manifest entry does not help in this case: using module currently only provides parse-time access to PowerShell class and enum definitions from modules, not also to types from binary assemblies (which, as with using assembly, are currently not loaded at parse time; additionally, even class and enum parse-time access doesn't currently work in param(...) blocks - see #19676 (comment)).

[mklement0]

I misspoke earlier about using a module with a RequiredAssemblies manifest entry being a viable workaround - it isn't, for the same reason that using assembly doesn't work. I've updated the previous comment accordingly.