The following CmdLets are expected to be available in Nano but are not:
Where do they come from? (What module?)
Current design decision is that PowerShell Core doesn't include system32/windowspowershell into the module path as those modules are likely not to work until they've been ported to CoreCLR. The test needs to be updated for PowerShell Core so that automodule loading expectations are different
I verified all of these load if you add $env:Windir\system32\windowsPowerShell\v1.0\Modules
to $env:psmodulepath
@SteveL-MSFT This is not true on Nano, so it would seem we should include the path on Nano.
Per Hitesh, this should work on Nano and IoT
@SteveL-MSFT adding High Priority here because it's something we need to close on for Nano Server by our RC.
@xumins we should talk about this in our next sync.
@joeyaiello based on our last discussion with Nano team, it seems we can take this off 6.0.0-HIghPriority
Just to summarize before I pull this off of HighPriority
: I believe the fix here is basically to somehow include system32
in the PowerShell Core on Nano when those modules are present.
@joeyaiello perhaps the way to solve this problem is a StartupConfig setting to include WindowsPowerShell module path?
@SteveL-MSFT This fix would be specific to nano
One possible fix - we don't change PSModulePath at all, instead we create symbolic links under PowerShell Core's $PSHome\Modules
path to the tested Windows PowerShell modules.
This way, we don't pick up everything from Windows PowerShell, only stuff we've tested.
May I comment that although this issue is labelled OS-Windows, most of this list are things we'd want to have cross-platform, e.g. Get-Net* ?
@chrisfcarroll Could you please open new Issue and enumerate all needed portable cmdlets Get-Net*?
Also adding how you would use them would be useful.
This specific issue should be addressed by the WindowsPSModulePath module on PSGallery
Noted ; and thankyou. I opened https://github.com/PowerShell/PowerShell/issues/6076
Most helpful comment
One possible fix - we don't change PSModulePath at all, instead we create symbolic links under PowerShell Core's
$PSHome\Modules
path to the tested Windows PowerShell modules.This way, we don't pick up everything from Windows PowerShell, only stuff we've tested.