Repository navigation
Import-Module with -UseWindowsPowerShell and PSModuleAutoLoadingPreference=None silently fails to create proxies #12043
Description
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-WmiObjectExpected 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
Reacted by Michael Klement
Activity
anmenaga commentedon Mar 6, 2020
This is fixed by #11980
In short: depending on the value of
PSModulePath- in the default case - this lineImport-Module Microsoft.PowerShell.Management -UseWindowsPowerShell -wa siwill import version7.0.0.0of the module in Windows PowerShell, so there is no surprise thatGet-WmiObjectis not found.This can be checked by running following in the end of repro steps:
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 simklement0 commentedon Mar 21, 2020
Andrew (@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 allMicrosoft.PowerShell.Managementcmdlets with implicitly-remoting WinPS proxy functions, which causes the problems described in Get-Item for files outputs PSObject instead of FileSystemInfo after Get-WmiObject #12014.The problem here is that in recent Windows 10 versions - as of at least version
1909- theC:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Managementmodule is unexpectedly - and, I presume, inappropriately - tagged as being PS Core-compatible - see Bug with set-location/cd/pushd command #12172 (comment) (update: a fix is pending).microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.