Powershell: Unable to find type when using PS 5 classes

Question

I'm using classes in PS with WinSCP Powershell Assembly. In one of the methods I'm using various types from WinSCP.

This works fine as long as I already have the assembly added - however, because of the way Powershell reads the script when using classes (I assume?), an error is thrown before the assembly could be loaded.

In fact, even if I put a Write-Host at the top, it will not load.

Is there any way of forcing something to run before the rest of the file is parsed?

Transfer() {
    $this.Logger = [Logger]::new()
    try {

        Add-Type -Path $this.Paths.WinSCP            
        $ConnectionType = $this.FtpSettings.Protocol.ToString()
        $SessionOptions = New-Object WinSCP.SessionOptions -Property @{
            Protocol = [WinSCP.Protocol]::$ConnectionType
            HostName = $this.FtpSettings.Server
            UserName = $this.FtpSettings.Username
            Password = $this.FtpSettings.Password
        }

Results in an error like this:

Protocol = [WinSCP.Protocol]::$ConnectionType
Unable to find type [WinSCP.Protocol].

It is the first line in the try block. But it doesnt matter where I load it. Even if I put the cmdlet on the topmost line with a direct path to WinSCPnet.dll, it won't load - it detects the missing types before running anything, it seems. — dbso

mklement0 mklement0 · Accepted Answer · 2017-03-16T16:40:37

As you've discovered, PowerShell refuses to run scripts that contains class definitions that reference then-unavailable (not-yet-loaded) types - the script parsing stage fails.

As of PSv5.1, even a using assembly statement at the top of a script does not help in this case, because in your case the type is referenced in the context of a PS class definition - this may get fixed in PowerShell Core, however; the required work is being tracked in this GitHub issue.

The proper solution is to create a script module (*.psm1) whose associated manifest (*.psd1) declares the assembly containing the referenced types a prerequisite, via the RequiredAssemblies key.

^{See alternative solution at the bottom if using modules is not an option.}

Here's a simplified walk-through:

Create test module tm as follows:

Create module folder ./tm and manifest (*.psd1) in it:

# Create module folder
mkdir ./tm

# Create manifest file that declares the WinSCP assembly a prerequisite.
# Modify the path to the assembly as needed; you may specify a relative path, but
# note that the path must not contain variable references (e.g., $HOME).
New-ModuleManifest ./tm/tm.psd1 -RootModule tm.psm1 `
  -RequiredAssemblies C:\path\to\WinSCPnet.dll

Create the script module file (*.psm1) in the module folder:

Create file ./tm/tm.psm1 with your class definition; e.g.:
```
class Foo {
  # Simply return the full name of the WinSCP type.
  [string] Bar() {
    return [WinSCP.Protocol].FullName
  }
}
```
Note: In the real world, modules are usually placed in one of the standard locations defined in $env:PSMODULEPATH, so that the module can be referenced by name only, without needing to specify a (relative) path.

Use the module:

PS> using module ./tm; (New-Object Foo).Bar()
WinSCP.Protocol

The using module statement imports the module and - unlike Import-Module - also makes the class defined in the module available to the current session.

Since importing the module implicitly loaded the WinSCP assembly thanks to the RequiredAssemblies key in the module manifest, instantiating class Foo, which references the assembly's types, succeeded.

If your use case doesn't allow the use of modules, you can use Invoke-Expression in a pinch, but note that it's generally better to avoid Invoke-Expression in the interest of robustness and so as to avoid security risks^[1] .

# Adjust this path as needed.
Add-Type -LiteralPath C:\path\to\WinSCPnet.dll

# By placing the class definition in a string that is invoked at *runtime*
# via Invoke-Expression, *after* the WinSCP assembly has been loaded, the
# class definition succeeds.
Invoke-Expression @'
class Foo {
  # Simply return the full name of the WinSCP type.
  [string] Bar() {
    return [WinSCP.Protocol].FullName
  }
}
'@

(New-Object Foo).Bar()

^{[1] It's not a concern in this case, but generally, given that Invoke-Expression can invoke any command stored in a string, applying it to strings not fully under your control can result in the execution of malicious commands.
This caveat applies to other language analogously, such as to Bash's built-in eval command.}

Powershell: Unable to find type when using PS 5 classes

4 Answers