PR Summary

Implementation for 'Importing Windows PowerShell modules in PowerShell Core' RFC.

• Modules, that are non-compatible with PS Core and were previously generating PSEditionNotSupported error, are now loaded into a background Windows PowerShell process connected to PS Core using a WinPSCompatSession PS remoting session using redirected process streams transport (same one used by PS jobs).
• Behaviour can be forced using Import-Module -UseWindowsPowerShell
• Module autoload during command discovery is supported
• a warning is displayed when a module is loaded into compat Windows PS.
• a new telemetry type is added and reported when a module is loaded into compat Windows PS.
• operations that do not work on de/serialized objects can be done in WinPSCompatSession remoting session $s = Get-PSSession -Name WinPSCompatSession; Invoke-Command -Session $s -ScriptBlock {Get-WinPSLiveObject | Set-WinPSLiveObject}
• new functionality is under PSWinCompat experimental feature.

Example:

PR Context

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s): PSWinCompat
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed: Need documentation for WinCompat functionality MicrosoftDocs/PowerShell-Docs#5092
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).