-
Notifications
You must be signed in to change notification settings - Fork 129
Importing Windows PowerShell modules in PowerShell Core #226
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
Conversation
Co-Authored-By: Steve Lee <[email protected]>
Co-Authored-By: Steve Lee <[email protected]>
Co-Authored-By: Steve Lee <[email protected]>
PS C:\> $PSVersionTable.PSEdition | ||
Core | ||
PS C:\> Import-Module DesktopOnlyModuleOnSystem32ModulePath | ||
VERBOSE: Please note that module 'DesktopOnlyModuleOnSystem32ModulePath' is imported in a remote Windows PowerShell session, so all objects that are returned by commands from this module are deserialized and are not 'live' objects. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that user scripts will works well with deserialized objects. I always had problems when I switched to deserialized objects. I'd expect that we use the technology only for modules compatible with serialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, I think it's impossible for us to know whether that's the case. I still think we're going to end up with more successful script executions if we automatically load system32 modules (which are known to be incompatible post-Server 2019 and are demarcated as such) than if we simply fail to load them
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to have a -UseWindowsPowerShell
type switch for Import-Module
to allow explicit use of this feature for modules outside of system32
What about providers? How will this enable working with a custom PSDrive that gets created when an incompatible module is loaded in the remote session? The WebAdministration module that ships with IIS on Windows 10 is a good example of a module that needs interaction with the custom provider via core cmdlets to perform automation properly. |
Couple questions/comments from @PowerShell/powershell-committee today:
|
|
Added 'Module blacklist' section. |
|
||
This feature has a significant performance cost - a Windows PS process needs to be started and PS Remoting channel established. This can be a problem in some cases considering this feature also loads modules automatically during command discovery. | ||
Some modules don't work well with de/serialized objects (e.g. pipeline cmdlet combinations of 'Hyper-V' module);<br /> | ||
Also there are cases when user never intended to load a module using this feature: for example, using any '-Job' cmdlet tries to load (and currently quietly fails) PS-Core-incompatible 'PSScheduledJob' module. With this feature enabled, 'PSScheduledJob' module is getting successfully loaded even though user never wanted it.<br /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like this one got fixed
### Module deny list | ||
|
||
This feature has a significant performance cost - a Windows PS process needs to be started and PS Remoting channel established. This can be a problem in some cases considering this feature also loads modules automatically during command discovery. | ||
Some modules don't work well with de/serialized objects (e.g. pipeline cmdlet combinations of 'Hyper-V' module);<br /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't Hyper-V already work natively? Or is there something here because of the SxS Hyper-V module versions?
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
2-Draft-Accepted/RFCNNN-Importing-Windows-PowerShell-modules-in-PowerShell-Core.md
Outdated
Show resolved
Hide resolved
…n-PowerShell-Core.md Co-Authored-By: Joey Aiello <[email protected]>
Unanimous consensus to accept from the Committee
Now that this PR is merged and the legacy project closed; if we're finding issues with the capability layer (such as PowerShell/WindowsCompatibility#89) should they be relocated to the main project? |
RFC about Importing Windows PowerShell modules in PowerShell Core.