Set 'PowerShellVersion' to 3.0 for built-in modules to make Windows PowerShell work when starting from PSCore #7365
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Summary
Fix #7324
The
PowerShellVersionfields in PSCore built-in modules were changed to6.1to reflect the current version of PSCore (new cmdlets were added in 6.1 timeframes). However, this breaking the scenario where a user needs to start Windows PowerShell from PSCore because the PSCore built-in modules will be found first and loaded by default, and the loading fails because they require a powershell of version 6.1.Set
PowerShellVersionto3.0for built-in modules to make Windows PowerShell work when starting from PSCore. This is a temporary workaround. We have the RFC PowerShell/PowerShell-RFC#133 submitted to address this issue by introducing a new environment variable representing PSModulePath for PSCore. Once we implement that RFC, this problem will go away. See #7324 (comment) for more information.PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests