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
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
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
$PSModuleAutoLoadingPreferencetoNoneand explicitly importing required modules into each module. Turning off module auto-loading, however, seems to result in the silent failure ofImport-Module -UseWindowsPowerShell. Proxy commands in that condition don't seems to be created despite thatImport-Module -UseWinidowsPowerShellproduces no error.Steps to reproduce
Expected behavior
Actual behavior
Environment data