Repository navigation
Microsoft.WinGet.Client depends on PowerShell 7 #3183
Description
According to the Quick Start Guide in https://github.com/microsoft/winget-cli/tree/master/src/PowerShell/Microsoft.WinGet.Client, the module requires Powershell and not Windows PowerShell. But the minimum version that is specified in the PowerShell Gallery is 5.1.0. (which is the Windows PowerShell version)
So what really is the minimum required version?
Originally posted by rollingmoai in #3182 (comment)
Activity
denelon commentedon Apr 25, 2023
Microsoft.WinGet.Client does need PowerShell 7 today. We need to update the module to properly reflect the requirements. We also need to remove some of the crescendo metadata as the module had to be manually rewritten to expose rich PowerShell objects.
[-]According to the [Quick Start Guide](https://github.com/microsoft/winget-cli/tree/master/src/PowerShell/Microsoft.WinGet.Client#quick-start-guide) in https://github.com/microsoft/winget-cli/tree/master/src/PowerShell/Microsoft.WinGet.Client, the module requires Powershell and not Windows PowerShell. But the minimum version that is specified in the PowerShell Gallery is 5.1.0. (which is the Windows PowerShell version)[/-][+]Microsoft.WinGet.Client depends on PowerShell 7[/+]rollingmoai commentedon Apr 27, 2023
Greg Wojan (@gwojan) Yeah, ideally the module should work with Windows PowerShell too.
damirkasper commentedon Apr 30, 2023
Please reconsider adding support for PS 5.1.
Until Windows OS ships with PS7 as part of the baseline OS deployment this is a fairly significant impact. You are asking teams to deploy, patch, manage PS7 just to support being able to use these modules. That is a fairly significant impact from an app management and patching perspective as well as additional risk surfaces to maintain.
I think this would be a different if PS7 was an in-place over the top upgrade and replacement for PS5.1. Most enterprises that would be interested in using this will likely run into a ton of friction due to needing PS7.
ethanbergstrom commentedon Jun 4, 2023
To piggy-back onto this - I'm not able to switch my OneGet or AnyPackage providers over to leveraging the official WinGet PowerShell module for provider interaction due to both package manager abstraction ecosystems supporting Windows PowerShell 5.1 and Desired State Configuration 1.1. See ethanbergstrom/winget#14 as an example of the features that would have to be removed.
Which, in turn, means I have to continue maintaining my Crescendo module, and all the hoop-jumping involved with parsing and cleaning up WinGet's often-mangled CLI output.
I was hoping to archive that project, but doesn't look like I can yet. Are there plans to add PS 5.1 compatibility to the module?
denelon commentedon Jun 5, 2023
We're still working through the matrix of requirements to get to support for Windows PowerShell. I'd like to be able to support it, but we ran into several complex scenarios getting everything to work in both Windows PowerShell and PowerShell 7 using the same module.
byjrack commentedon Sep 26, 2023
Any updates on a strategy to support both 5.1 and 7+? If supporting in the same module is too challenging what about supporting modules for 5 and for 7?
Been trying to look into using it with our Company Portal for evergreen installs of machine scoped apps, but it's getting tougher and tougher to build the requirements for a given Program. I need to carry a ps7 bootstrap, the client psm, and make sure that nuget etc are in good shape. Definitely possible, but hoping to make things more factory for our team.
piotrminkina commentedon Nov 7, 2023
It would be very nice if there would be WinGet support for PowerShell 5.1, which is installed by default with Windows. Such good support is currently lacking.
jszabo98 commentedon Feb 3, 2024
Saying "Minimum PowerShell version 5.1.0" is very confusing.
rollingmoai commentedon Mar 8, 2024
Resolved by #3951?
byjrack commentedon Mar 8, 2024
I have not tested it thoroughly, but for the moment it looks like I have all the major cmdlets working in 5.1 so looking forward to deprecating my wrapper and get this going.
byjrack commentedon Mar 8, 2024
Found a big gotcha.... even with starting powershell in MTA it looks like these cmdlets in 5.1 won't function in SYSTEM context. Won't be able to use it in our use case which is orchestration via Intune IME. There are some apps that we are doing in User, but lots that we publish are still dependent on admin rights for some feature and given we can't handle UAC in these cases we will need to stick with the wrapper module.
I keep hoping the Intune team will consider supporting generic package manager sources vs only Store, but doesn't seem to be any interest in that thus far.
And yeah now i notice the #3951 specifically notes "user context" and just missed that detail in my excitement.
byjrack commentedon Mar 8, 2024
Demitrius Nelon (@denelon) just to set my own expectations. Will there be work done to make these cmdlets work in SYSTEM context or is the apartment and context handling with COM just too complicated to do securely? Completely get if not, but trying to keep some hope alive that I can smooth out our Intune orchestration.