-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get-Item for files outputs PSObject instead of FileSystemInfo after Get-WmiObject #12014
Comments
/cc @PaulHigin -- looks like we need to add some explicit exclusions to cmdlets we're importing from a Windows PowerShell module. @alx9r in the meantime, I would recommend simply using |
Nice diagnosis. Yeah we need to solve the module encapsulation of the Windows PowerShell modules, and possibly exclude some WinPS modules from imports. I've been thinking we need to write a simple proxy module that only exposes the different commands from the WinPS modules. |
@vexx32 Thank you very much for explaining how that's happening. I confirmed your explanation with this example: .{
Get-Command Get-Item
Get-WmiObject bogus -ea si
Get-Command Get-Item
} |
% {[pscustomobject]@{
CommandType = $_.CommandType
ModulePath = $_.Module.Path
}}
which outputs
|
It doesn't help in the issue. We discussed this earlier. The example shows that we need "import" only one cmdlet from the module. And my suggestion was that we need to have a white list. Otherwise we import whole WinPS Microsoft.PowerShell.Management and overload PS Core Microsoft.PowerShell.Management. Alternative proposal was to make second one more high priority in discovering process, |
My thinking was to use a wrapper module that imports the WinPS module as a nested module and only exposes the commands that we want to add to the PS 7 session. However, playing with that now I'm not sure how possible that is. |
Looks like I've found a new bug in PowerShell! Try this: New-ModuleManifest -path ./wincompat.psd1 -NestedModules 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Microsoft.PowerShell.Management\Microsoft.PowerShell.Management.psd1' -CmdletsToExport 'Get-EventLog'
Import-Module ./wincompat.psd1
Get-EventL<Tab> # Completes Get-EventLog
Get-EventLog # Command not found |
I'd expect that |
But we support that! The 5.1 Microsoft.PowerShell.Management.dll is importable into PowerShell. The problem is the way commands exported from it currently override things |
I guess you mean "the binary can be loaded" but we can not support the 5.1 module on 7.0. A similar module importing happened when we had a mess with the module paths. My suggestion was explicitly disable this for modules in the repo.
|
@rjmholt @iSazonov @vexx32 I've been experimenting with this behavior. My findings suggest that the impact of how PowerShell 7 resolves names is broader than just what occurs when a Windows PowerShell module is imported. There seems to have been a change to how names are resolved between 5.1 and 7. That change introduces name resolution side-effects, in general, between modules. I haven't to be able to reproduce that in 5.1. I have opened #12036 which is a repro of a similar issue to this but not involving WIndows PowerShell at all. If you have a chance please take a look at that issue too. |
Can you give an example where this new behaviour is causing an issue? It would help us pin down the change and the issue |
Good ideas on this thread. The original issue with |
(I wasn't sure which "new behavior" you were asking about. I answered for the new module resolution behavior over on #12036.) @rjmholt The new behavior of auto-importing of Windows PowerShell proxy commands caused a problem during the same PowerShell 5.1 to 7 transition I described here and it occurred in a similar manner to that story: I had a module that invoked |
Thanks for looking into this so deeply @alx9r |
Another idea is to replace |
🎉This issue was addressed in #12269, which has now been successfully released as Handy links: |
🎉This issue was addressed in #12269, which has now been successfully released as Handy links: |
Get-Item
normally outputs System.IO.FileInfo or System.IO.DirectoryInfo objects for the FileSystem provider. After invokingGet-WmiObject
, however,Get-Item
outputs PSObject objects instead. This causes binding to any command expecting one of the specific FileSystemInfo types to fail.Steps to reproduce
Expected behavior
Actual behavior
Environment data
The text was updated successfully, but these errors were encountered: