Powershell: Import-Module with -UseWindowsPowerShell and PSModuleAutoLoadingPreference=None silently fails to create proxies

[alx9r]

I've been trying to find some kind of practical workaround for the name collisions described in #12036 and #12014. One avenue that seemed worth exploring is setting $PSModuleAutoLoadingPreference to None and explicitly importing required modules into each module. Turning off module auto-loading, however, seems to result in the silent failure of Import-Module -UseWindowsPowerShell. Proxy commands in that condition don't seems to be created despite that Import-Module -UseWinidowsPowerShell produces no error.

Steps to reproduce

$PSModuleAutoLoadingPreference = [System.Management.Automation.PSModuleAutoLoadingPreference]::None
Import-Module Microsoft.PowerShell.Utility,Microsoft.PowerShell.Management
Import-Module Microsoft.PowerShell.Management -UseWindowsPowerShell -wa si
Get-Command Get-WmiObject

Expected behavior

Function

Actual behavior

Get-Command: C:\test.ps1:4
Line |
   4 |  Get-Command Get-WmiObject | % CommandType
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~
     | The term 'Get-WmiObject' is not recognized as the name of a cmdlet, function, script file, or operable program.
     | Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 6.3.9600
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[anmenaga]

This is fixed by #11980

In short: depending on the value of PSModulePath - in the default case - this line Import-Module Microsoft.PowerShell.Management -UseWindowsPowerShell -wa si will import version 7.0.0.0 of the module in Windows PowerShell, so there is no surprise that Get-WmiObject is not found.
This can be checked by running following in the end of repro steps:

PS C:\> $s = Get-PSSession -Name WinPSCompatSession
PS C:\> Icm $s {Get-Module -Name Microsoft.PowerShell.Management}

ModuleType Version    PreRelease Name                                ExportedCommands                           PSComputerName
---------- -------    ---------- ----                                ----------------                           --------------
Manifest   7.0.0.0               Microsoft.PowerShell.Management     {New-ItemProperty, Set-Item, Push-Locatio… localhost

A workaround can be loading module by path:
Import-Module "$env:windir\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management\Microsoft.PowerShell.Management.psd1" -UseWindowsPowerShell -wa si

[mklement0]

@anmenaga:

Without having looked at #11980:

• The suggested workaround is effective with respect to the ability to call Get-WmiObject, but has the major side effect of replacing all Microsoft.PowerShell.Management cmdlets with implicitly-remoting WinPS proxy functions, which causes the problems described in #12014.

• The problem here is that _in recent Windows 10 versions_ - as of at least version 1909 - the C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management module is unexpectedly - and, I presume, _inappropriately_ - tagged as _being PS Core-compatible_ - see https://github.com/PowerShell/PowerShell/issues/12172#issuecomment-602100870 (update: a fix is pending).