Skip to content
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

Importing Windows PowerShell modules in PowerShell Core #226

Merged
merged 22 commits into from
Feb 19, 2020

Conversation

anmenaga
Copy link
Contributor

RFC about Importing Windows PowerShell modules in PowerShell Core.

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.
Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Member

@SteveL-MSFT SteveL-MSFT left a 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

@KirkMunro
Copy link
Contributor

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.

@joeyaiello
Copy link
Contributor

joeyaiello commented Oct 21, 2019

Couple questions/comments from @PowerShell/powershell-committee today:

  • @daxian-dbw wondered why we didn't use the same transport leveraged by PSJobs (where the powershell.exe process is launched in "server mode") vs. named pipes
  • @JamesWTruher raised that the user is likely not going to be expected deserialized objects and it could be difficult to debug or understand what's going on in long-running tasks. We should do some validation of basic of real-world scripts that leverage known incompatible modules (like ServerManager) e.g. Docker's install script.
  • While maybe not enough, we agree that we should definitely throw a warning that powershell.exe is going to be used, that a deserialized object will be emitted, and that Import-Module -SkipEditionCheck can be used if you know what you're doing to explicitly load the module into the PowerShell Core.
  • Similarly, we should do this for auto-loading of modules at cmdlet execution time.
  • @daxian-dbw also raised that the debug channel is likely occupied by this as long as the powershell process is open (which is the case so long as any Windows PS modules are imported). To me, this is a bit of a showstopper, and we should investigate the jobs channel to see if that could alleviate our problem here.
  • We should validate that, given that the proxy module is the same name as the original module, our new module telemetry reports that the proxy module was imported if it's in our first-party allow list

@anmenaga
Copy link
Contributor Author

anmenaga commented Nov 5, 2019

  • Added -UseWindowsPowerShell parameter to allow explicit use of this feature for modules outside of system32
  • providers are not covered by this. Added this point to Alternate Considerations. In some cases, doing the entire scenario, that can not be split on remoting boundaries, is possible since the WinCompat remoting session is available Invoke-Command -Session WinPSCompatSession -ScriptBlock {Get-WinPSLiveObject | Set-WinPSLiveObject}
  • PS transport was changed to the one used by PSJobs; Valid point about IPC channel blocking debugging of WinPS.
  • added a warning to be generated every time a module is imported using this new functionality
  • added that new functionality should also be supported during module autoload / command discovery.
  • added new telemetry type.

@anmenaga
Copy link
Contributor Author

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 />
Copy link
Contributor

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 />
Copy link
Contributor

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?

…n-PowerShell-Core.md

Co-Authored-By: Joey Aiello <joeyaiello@users.noreply.github.com>
Unanimous consensus to accept from the Committee
@joeyaiello joeyaiello merged commit c2ed0e8 into PowerShell:master Feb 19, 2020
@aolszowka
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants