Importing Windows PowerShell modules in PowerShell Core #10973
Conversation
|
This PR might impact tooling, because it might be necessary to debug a module imported via compat. |
Given that this is to be a builtin feature, the user experience might be better if encapsulated: Invoke-InWinPSCompatibilitySession { Get-WinPSLiveObject | Set-WinPSLiveObject } |
@alexbuzzbee could you expand on this with an example? What scenario are you envisaging here? Also, it might be best to have this discussion in the RFC. |
|
Say you have a script module that was written as Windows-specific (because it uses Windows P/Invokes, COM, or Windows-specific .NET APIs), but need to use it in a modern script. A problem is happening inside the Windows-specific module. You need to debug inside it, so the debugging tools need to be able to see and work inside the Windows PowerShell compat session. Yes, it might be possible to reproduce the issue using a Windows PowerShell script instead, but that would usually be significantly more effort than just debugging the module. It might be correct that this should go in the RFC; I was just going off the tooling checkboxes and noted that they might not be accurately filled. |
|
@alexbuzzbee Do these examples fall into scenario that you describe? Debugging from the same PS process: Debugging from another PS process: |
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/remoting/commands/newrunspacecommand.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/remoting/commands/newrunspacecommand.cs
Outdated
Show resolved
Hide resolved
|
@anmenaga All I was trying to point out is that the "I have considered the user experience from a tooling perspective and enumerated concerns in the summary" box should probably be checked instead of "I have considered the user experience from a tooling perspective and don't believe tooling will be impacted." |
src/System.Management.Automation/engine/Modules/ImportModuleCommand.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/remoting/client/remoterunspaceinfo.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
|
@anmenaga Is this PR ready for review? If so, please remove the |
There was a problem hiding this comment.
telemetry changes look good
src/System.Management.Automation/engine/Modules/AnalysisCache.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/AnalysisCache.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/AnalysisCache.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
Show resolved
Hide resolved
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/remoting/commands/CustomShellCommands.cs
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Management/Get-Process.Tests.ps1
Outdated
Show resolved
Hide resolved
| "Alias", "nsn", "New-PSSession", $($FullCLR -or $CoreWindows -or $CoreUnix), "", "", "" | ||
| "Alias", "nv", "New-Variable", $($FullCLR -or $CoreWindows -or $CoreUnix), "ReadOnly", "", "" | ||
| "Alias", "nwsn", "New-PSWorkflowSession", $($FullCLR ), "ReadOnly", "", "" | ||
| "Alias", "nwsn", "New-PSWorkflowSession", $($FullCLR -or $CoreWindows ), "", "", "" |
There was a problem hiding this comment.
Why do we need the change?
There was a problem hiding this comment.
this alias comes from PSWorkflow module which is incompartible with PS Core.
This test just loads all stuff from a hardcoded set of modules and checks against this huge table; PSWorkflow is one of them. With this PR module can actually be successfully loaded on PS Core and the alias shows up, and the test did not expect this.
There was a problem hiding this comment.
DefaultCommands.Tests is designed to tracking that is explicitly in PowerShell Core on different platforms and show difference from Windows PowerShell.
If the test failed I guess it is side effect from other tests and just the tests must do right cleanup.
src/System.Management.Automation/engine/Modules/AnalysisCache.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/AnalysisCache.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
Outdated
Show resolved
Hide resolved
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
Show resolved
Hide resolved
src/System.Management.Automation/engine/remoting/commands/newrunspacecommand.cs
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Core/CompatiblePSEditions.Module.Tests.ps1
Outdated
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Core/CompatiblePSEditions.Module.Tests.ps1
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Core/CompatiblePSEditions.Module.Tests.ps1
Show resolved
Hide resolved
src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs
Outdated
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Core/Enter-PSHostProcess.Tests.ps1
Show resolved
Hide resolved
test/powershell/Modules/Microsoft.PowerShell.Management/Get-Process.Tests.ps1
Show resolved
Hide resolved
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
Show resolved
Hide resolved
|
@anmenaga Can you please resolve the conflict, again :) |
|
Great work @anmenaga ! |
|
🎉 Handy links: |
PR Summary
Implementation for 'Importing Windows PowerShell modules in PowerShell Core' RFC.
PSEditionNotSupportederror, are now loaded into a background Windows PowerShell process connected to PS Core using aWinPSCompatSessionPS remoting session using redirected process streams transport (same one used by PS jobs).Import-Module -UseWindowsPowerShellWinPSCompatSessionremoting session$s = Get-PSSession -Name WinPSCompatSession; Invoke-Command -Session $s -ScriptBlock {Get-WinPSLiveObject | Set-WinPSLiveObject}PSWinCompatexperimental feature.Example:
PR Context
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.PSWinCompat