PowerShell: Unable to find type [System.Windows.Forms.MessageBox].

Unable to find type [System.Windows.Forms.MessageBox]. means PowerShell evaluated a type literal in square brackets and no loaded assembly defines that type. Most often the assembly is simply not loaded: run Add-Type -AssemblyName System.Windows.Forms before using the type. Other causes are a typo in the namespace, a class from a module imported with Import-Module instead of using module, and types that exist only in Windows PowerShell 5.1 (.NET Framework) or only in PowerShell 7 (.NET).

Reproduce it

$ErrorActionPreference = 'Stop'
try { [System.Windows.Forms.MessageBoxButtons]::OKCancel } catch { $_.Exception.Message; '  -> ' + $_.FullyQualifiedErrorId }
Add-Type -AssemblyName System.Windows.Forms
[System.Windows.Forms.MessageBoxButtons]::OKCancel
try { [Sytem.IO.Path]::GetExtension('a.txt') } catch { $_.Exception.Message }
[System.IO.Path]::GetExtension('a.txt')

Unable to find type [System.Windows.Forms.MessageBoxButtons].
  -> TypeNotFound
OKCancel
Unable to find type [Sytem.IO.Path].
.txt

Assemblies that are not loaded by default

Use [System.AppDomain]::CurrentDomain.GetAssemblies() to list what is loaded in the session.

Types used before Add-Type runs

PowerShell resolves types in param() blocks, class definitions and attribute declarations when it parses the script, before the first line runs. An Add-Type at the top of the same script is too late for those uses. Load the assembly in the calling script or profile, or move the typed code into a function in a second file that you dot-source after Add-Type.

Classes from modules

using module MyTools       # must be the first statement in the script
[MyToolsConfig]::new()     # works; after Import-Module MyTools the class is not visible