GeezerVison

PR Summary

Fix #114
Also fix the following PowerShell issues:

• #requires -Modules fails in Enter-PSSession remoting session (PowerShell.7 endpoint) — regression from 7.4 to 7.6 PowerShell#27907
• Remote session (wsmprovhost.exe) cannot resolve assemblies due to PowerShellAssemblyLoadContext being initialized with empty basePaths PowerShell#27982
• ActiveDirectory module does not work over remoting in PS 7.6 PowerShell#27199

Replace the hard-coded Trusted Platform Assemblies (TPA) allow-list used by pwrshplugin.dll with a deny-list constructed from the DLLs installed alongside .NET runtime.

Motivation

The set of trusted platform assemblies differs across supported PowerShell versions, including 7.4, 7.5, and 7.6. Maintaining an explicit allow-list causes the WinRM hosting code to fall out of sync as assemblies are added, removed, or renamed.

Comparing TRUSTED_PLATFORM_ASSEMBLIES from pwsh.exe with the DLLs under $PSHOME showed that the TPA list is consistently the set of installed DLLs minus a relatively stable group of native and host binaries.

Changes

• Enumerate *.dll files immediately under coreCLRDirectoryPath.
• Include each discovered DLL in the TPA list unless it is a known native or host binary.
• Match deny-list entries case-insensitively.
• Exclude files beginning with mscordaccore_ to account for architecture- and version-specific filenames.
• Exclude Microsoft.PowerShell.GraphicalHost.dll, which is not usable in a remoting session.
• Include other PowerShell managed assemblies in the TPA list.
• Remove the obsolete .ni.dll probing logic because modern PowerShell distributions no longer include native-image assemblies.
• Remove outdated comments.
• Add FindFirstFileA, FindNextFileA, and FindClose to the existing system-call facade so directory enumeration follows the current dependency-injection design.

This makes TPA construction resilient to assembly changes across PowerShell and .NET servicing releases while retaining a small, stable deny-list.