Add Native PowerShell Support

[ThomasNieto]

Description of the new feature/enhancement

A vast majority of Windows automation is done with PowerShell. To support those users create and ship a winget PowerShell module on PowerShell Gallery.

[aglasson]

A colleague of mine sent me a link to the Windows Package Manager Preview blog article just now. The first thing I said to myself was "Why is this a command line application and not a native Powershell cmdlet?". I'm surprised any new command only software from Microsoft isn't Powershell (dotnet/core based) let alone not with Powershell out of the box.
This might just be my naivety showing through.
I'm genuinely curious as to the reasons for that, if any of the devs can provide insight?
Is it perhaps related to this being delivered via the Microsoft Store?

[ethanbergstrom]

I've started actively working on a new PackageManagement provider that can lay over the top of WinGet. Based a quick review the CLI doesn't look too different from Chocolatey, so it shouldn't be difficult to adapt to it as a gap-filler until Microsoft puts out something official.

Edit: Initial work on the provider is complete! See below.

[AurimasNav]

The one thing I dislike about chocolatey is having to deal with those string outputs of commands in automation tasks, please make it so we can work with powershell objects.

[doctordns]

• 1 on this.

WInget is a great concept, badly let down by its UI. Here are my problems:

1. No Get-Help - existing help is thin to say the least
2. inconsistent command structure
3. No objects emitted or taken as a parameter
4. No Tab Completion making it harder to use
5. Output is string so no Get-Member to discover output - less discoverable
6. All in all harder to automate programmatically without having to go back to the stone age with grep/sed/.awk
7. Probably not based on .NET so less portable and less easy to leverage.

My view: Winget is a great product, let down by an underimagined UI. The team needs to re-read the Monad Manifesto, then come back with a better implementation.

Please add real cmdlets. Please make winget fully automatabile. Please bring back the consistency inherent with PowerShell.

[JasonFossen]

How could a project like this even get started without planning for PowerShell integration? The word "PowerShell" does not appear once on the Roadmap page for this project. Is this a turf war issue between different managers or technical fellows at Microsoft?

It's fine that winget does not require PowerShell, that's not the issue. But to not have a single word about PowerShell integration as a primary design goal? Is the plan to have PowerShell parse the text output of winget be like parsing the output of ipconfig or netstat, like it's 1995 again? At least have a command line switch to output JSON or XML.

Did your team talk to any Windows systems administrators outside of Microsoft when scoping out this project's design requirements? Mom & Pop are not managing applications from the command line. Please poll some enterprise administrators and ask them how important they feel it is to have optional but baked-in PowerShell integration (not just basic cli compatibility). Maybe some of them would like to chime in here...

[ethanbergstrom]

I have my first attempt at a stop-gap PackageManagement provider up on PSGallery this morning, it should work on both PowerShell 3 through 5.1 and 7.0.1+.

I've noticed on first run that it's somewhat flaky about initially caching the package list from the repo if winget has never been used before. Running a cmdlet a second time after initial install seems to work. Still looking into that piece.

Not being able to pull a list of installed packages also seems to give PackageManagement some heartburn..

PS C:\Users\WDAGUtilityAccount> Install-PackageProvider WinGet -Force                                                   
Name                           Version          Source           Summary
----                           -------          ------           -------
PackageManagement              1.4.7            PSGallery        PackageManagement (a.k.a. OneGet) is a new way to d...
WinGet                         0.0.1            PSGallery        Package Management (OneGet) provider that facilitat...

PS C:\Users\WDAGUtilityAccount> Install-Package 7zip -ProviderName WinGet -Force
WARNING: 'WinGet': Get-Package is not supported because WinGet does not support listing installed packages. «-f»
«WinGet»

Name                           Version          Source           Summary
----                           -------          ------           -------
7zip.7zip                      19.0.0           winget

Edit: These issues are now solved. See below.

[MaxFrost]

So this is the second mention of needing powershell operability, and I think what we need is not for this project to provide powershell support directly, but instead provide parseable (not just string) output. The other issue #196 I think summed up the best option for this executable, which is provide a flag to generate json or XML output that is parseable by anything that can handle those formats. I believe that would be the best solution forward, and would also give a way for other systems to use the executable in a programmatic way, not just powershell.

[vexx32]

I think that's a decent halfway solution @MaxFrost.

Ideally, we'd get that and a PowerShell module built around that to make handling it easier. Providing parseable output is a good first step, and would at least allow the community to build a powershell module to handle it.

However, I think it'd be a much better idea for the team building WinGet to also build the powershell module so they can have new features handled in the powershell module at more or less the same time as they release new features to the application itself.

[jdhitsolutions]

I've spent my entire morning building my own PowerShell wrapper. What a mess. What do you think the ratio is of people who will run this in PowerShell vs a CMD window? I crave structured data. Heck, even if you added a -format option to output as json or CSV I could pipe the winget command to Powershell.
I'll also ask why I would use this over the PackageManagement module in PowerShell?

[AurimasNav]

I think that's a decent halfway solution @MaxFrost.
Ideally, we'd get that and a PowerShell module built around that to make handling it easier. Providing parseable output is a good first step, and would at least allow the community to build a powershell module to handle it.
However, I think it'd be a much better idea for the team building WinGet to also build the powershell module so they can have new features handled in the powershell module at more or less the same time as they release new features to the application itself.

People keep on mentioning powershell module, but I just want to stress it that we should focus on PackageManagement Provider (which techincally I guess is a module?), so we can utilize it's cmdlets for consistent experience across different managers.

[KevinMarquette]

It would be disappointing if it lacks PowerShell support. I would be happy to get either a CmdLet or a PackageManagement provider.

If you decide to build full Cmdlets, connect with the community early in the process. We are very vocal and good about providing feedback. We also have a good sense of the best practices and how to capture the spirit of PowerShell when creating new CmdLets. Like how naming your object properties and cmdlet parameters the same helps PowerShell to automatically map them on the pipeline without you having to create and manage a mapping between the two.

The provider would actually be the easiest to for you to implement, especially when you are still in development. It has a clear interface, the design requirements are already there, and you are in a place to identify features that would make that integration trivial. Like adding JSON output options that you are more than likely going to add anyway. The only documentation you would need is how to install the provider and an example showing how to download your first package for good measure. The rest of the documentation is covered by PackageManagement. You would reach a user base that already knows how to use the commands. And PackageManagement already has a DSC provider so that fits into your Asure story for host configuration and devops.

[KevinMarquette]

Not providing PowerShell support is signalling that this is just a tool for developers written by developers for local system installation. This announcement was timed for Build and what you presented was good for that development focused audience.

Native PowerShell support signals that this is a tool for system admins and system devs that are managing hosts in Azure with or without DevOps and also in corporate networks (especially if they support more than a hand full of systems).

[doctordns]

@KevinMarquette - you make a good point. I note that all negative social media comments remain without a reasoned response. I did see one MVP who tried to defend the approach but quickly backed down in the face of common sense.

I suspect that someone had a great idea for a new tool. In a common sense vacuum, they developed it in a Linux like fashion (ie random characters that make up this .exe's UI). This means users have to screw around with grep/sed/awk to do anything beyond trivial. What a sad state of affairs.

This reeks of re-inventing a wheel, Haven't MSFT learned the lessons of history? The PMs on this team should be forced to re-read the Monad Manifesto until they understand where they went so wrong.

TL;DR: A company that respects IT Professionals would never have designed this feature this poorly. Management of packages is a management activity that is inherently automatable.

This is very disappointing - another tool I really can not get excited about. It could have been so much better.

[jdhitsolutions]

I think the ultimate question is "Who is the target user for this command and in what likely use case?". I get the feeling this is designed and targeted at developers who might run this from a CMD prompt or somehow incorporate it into their projects.

[vexx32]

Sure... but even then, really, PowerShell is the default Windows shell nowadays, and there's no effort to integrate this with PS even on the roadmap.

[virtualas10]

This is very much the behaviour I would expect out of winget-cli. Really stops me from deep dive into it on the whole estate!

[doctordns]

Simply making winget produce 'better' text really misses the point. A real package management tool would today be based on objects with PowerShell. This tool is not an enterprise management tool or even part if an overall management solution. I see it as a developer tool and little more.

[doctordns]

@jdhitsolutions Jeff - I agree that this tool seems to be targeted at the developer running WIndows, with some Linux background who use this tool to manage their local development boxes. IT Pros, these days, expect PowerShell, remoting via PS remoting, and a rich object module. They expect to be able to script based on rich cmdlet output. They expect to use that rich model for reporting.

Devs with LInux experience necessarily have different expectations base on Linux. They do not mind the string output as they can grep/sed/awk their way to hacking automation. And for this persona, many of the features are important to IT Pros are less relevant for a dev managing his/her own local workstation.

But whatever the target market, winter is not an package manager in any sort of enterprise sense.

[doctordns]

Sure... but even then, really, PowerShell is the default Windows shell nowadays, and there's no effort to integrate this with PS even on the roadmap.

In this day and age, I would have expected the team to have started with a rich object model, then build the classes to support them, and finally layer the cmdlets on top. That gives you the ability to use the cmdlets as is or leverage the objects for more complex automation and/or reporting in an enterprise management setting.

This could have been so much better. :-(

[jdhitsolutions]

There's still time for this to "be so much better". There has only been 1 release with obviously a lot of work ahead. Especially if the goal is for true package management and not just another way to install something. All we can hope is that our comments reach the right ears and have the right effect.

[denelon]

One of the initial goals is to make sure the Windows Package Manager works on earlier versions of Windows without a PowerShell dependency. That is one of the primary reasons this is a .exe and written in C++.

[megamorf]

@denelon I'm sorry but that argument is void.

Windows 8.1 and Server 2012 are the oldest platforms that are still officially supported (extended support) and they shipped with PSv3. Windows 7 which has reached EOL shipped with built-in PSv2 and newer PS versions have been included in all subsequent Windows client and server releases. Platforms in extended support don't receive new features so they are not your target anyway.

if you want to cover everything in support:

• https://docs.microsoft.com/en-us/powershell/scripting/powershell-support-lifecycle?view=powershell-7#release-history
• https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet

Edit:
Also, C++ at this point in time seems to be a suboptimal choice when there are newer fast/secure alternatives like Golang and Rust.

[doctordns]

That is really not a great answer, in my view. MSFT and the industry have settled on PowerShell as a key automation tool for the IT Professional. Package management, that is the management of packages on a host, is a configuration management problem that is inherently automatable.

For any organisation, automation of Windows means PowerShell. Winget may do cool things, but it is by design MSFT made it harder to automate and harder to scale for an enterprise. It has, in my view, made a bad choice and one that is now harder to fix without a major bit of rework. Slapping cmdlets on top of an exe is not the way forward either. Lipstick on a pig, etc.

The team should go back to basics, define a rich object model, then add that model to .NET Core. The cmdlets almost write themselves. The feature would get much wider adoption instead of being a developer power toy.

[jantari]

There is one way to provide structured/object-oriented access to winget without the need to maintan a separate PowerShell module AND without re-working winget itself to be C#/PowerShell.

1. All functionality of winget is moved to a native C++ .dll
2. winget.exe will just be a tiny wrapper for calling into that dll
3. The dll will have all the needed functions exposed as public, and it can be imported in C# and PowerShell through [DllImport()]

This way we all get what we want - a PowerShell wrapper could also easily be community-maintaned - and it's 0 extra work for the winget devs.

[doctordns]

Why not just make them .Net (core!) classes?

[Atamido]

Here's an extremely simplistic code for what I feel the PowerShell module should be able to do - just took the Enable-WinGetLocalManifest code you linked earlier and modified it.

I'm neither a PowerShell guru nor did I do extensive reading on WinGet so, for example, I don't know if it can handle setting multiple different settings in one go. Everything here could be upgraded but it gives you the general idea.

function Set-WinGetSetting {
    [CmdletBinding()]
    PARAM (
        [Parameter()]
        [ValidateSet("Enable","Disable")]
        [String]
        $LocalManifestFiles = "",

        [Parameter()]
        [ValidateSet("Enable","Disable")]
        [String]
        $SomeOtherSetting = "",

        [Parameter()][switch]$VerboseLog
    )
    BEGIN {
        $WinGetArgs = $null
    }
    PROCESS {
        IF($LocalManifestFiles -ne ""){
            [string[]]$WinGetArgs = "Settings", "--$localManifestFiles", "LocalManifestFiles"
            $WinGetArgs += "--Verbose-Logs", $VerboseLog
            & "WinGet" $WingetArgs
        }

        IF($SomeOtherSetting -ne ""){
            [string[]]$WinGetArgs = "Settings", "--$SomeOtherSetting", "SomeOtherSetting"
            $WinGetArgs += "--Verbose-Logs", $VerboseLog
            & "WinGet" $WingetArgs
        }

        IF($null -eq $WinGetArgs){
            Write-Warning "No settings provided."
        }
    }
    END {
        return
    }
}

@Alaknar @denelon

I took this code and fleshed it out into a function that covers all of the WinGet setting stored in the settings.json, as well as the LocalManifestFiles setting (which appears to be the only setting not in settings.json). I pulled the settings and their validation criteria from the 0.2 schema stored here: https://github.com/microsoft/winget-cli/tree/master/schemas/JSON/settings

I wanted to show that, as Alaknar said, in this situation is makes much more sense to make a single "Set-WinGetSetting" function for configuring various WinGet settings. Otherwise you end up with unnecessary cmdlet/function sprawl, making user/administrators lives more complicated. Note that due to the fact that the settings don't exist by default, you'd also want another (much simpler) "Remove-WinGetSetting" to entirely delete a value.

https://github.com/Atamido/PowerShell/blob/master/Misc/Set-WinGetSetting.ps1

[denelon]

The first version of the PowerShell module is in the assets of the latest release. I've also pinned a discussion with some initial feedback, and submitted the first bug from the report:

• PowerShell pipe to sort fails #2798

[treestryder]

WinGet team, you will have to forgive us. What comes across as complaining is actually grief. Years of work on a holistic management framework, thrown away by thinking of Powershell as only a command line interface, just "another mechanism to call the existing functionality".

It could be overlooked if it weren't for the Windows, Store and Intune teams having adopted WinGet.

I see in this and the other threads many great suggestions by folks trying to help. In my mind, top among them would be implementing a PackagementManagement provider.

[felipecrs]

The first version of the PowerShell module is in the assets of the latest release. I've also pinned a discussion with some initial feedback, and submitted the first bug from the report:

• PowerShell pipe to sort fails #2798

I guess this means this issue can be closed then, no?

[ThomasNieto]

The first version of the PowerShell module is in the assets of the latest release. I've also pinned a discussion with some initial feedback, and submitted the first bug from the report:

• PowerShell pipe to sort fails #2798

I guess this means this issue can be closed then, no?

It should not be closed, the module is not published on the PowerShell Gallery.

[denelon]

LOL! You beat me to it. I wasn't planning on closing this until we publish in the PowerShell gallery. We have a bit more work to do around testing and automation before that can happen.

[manelrodero]

When will the module be available in the PowerShell Gallery?

We have seen that the PSD1 file is not included with the installation of winget v1.4.10052.

And right now I don't have an environment ready to compile it ;-)

[giggio]

How do we use the PowerShell module? I have the latest version, is it already installed? (v1.4.3132-preview)

[krokofant]

How do we use the PowerShell module? I have the latest version, is it already installed? (v1.4.3132-preview)

Look at the assets for the releases on Github. You can download e.g. Microsoft.WinGet.Client-PSModule.zip and load that.

[denelon]

Release notes includes the link to:

Information about getting started and usage can be found here.

[sitiom]

When will the module be available in the PowerShell Gallery?

For now, I have created a PR to add the module to Scoop. Once it's merged, you could simply install it from there:

• winget-ps: Add version 1.4.10173 ScoopInstaller/Main#4381 (winget-ps)

scoop install winget-ps
Import-Module Microsoft.WinGet.Client

[soroshsabz]

Please add full example to describe the usage of Powershell CLI (both standard pakcage mangement command (such as Find-Package) and specific WinGet commmand (such as Find-WinGetPackage) into the https://github.com/microsoft/winget-cli/tree/master/tools/PowerShell README.md

thanks

[denelon]

We will be publishing another release in the next few days.

I'll be giving a presentation at 2;00 PM on Tuesday April 25th.

I've created:

• Publish PowerShell Modules to PowerShell Gallery #3176

After we publish the initial preview release at the PowerShell Gallery, I will be closing this issue so we can track individual Issues on bugs and features related to the Microsoft.WinGet.Client module with the "PowerShell" label.

[Banner-Keith]

@denelon can we get an update on this issue when the official release goes out so we know we can start using it? I don't want to switch my scripts over in preview, but would love to do so once this is stable.

[denelon]

https://www.powershellgallery.com/packages/Microsoft.WinGet.Client/0.1.0-alpha

[denelon]

I created a discussion for the new Microsoft.WinGet.Client module.

• Microsoft.WinGet.Client 0.1.0-alpha #3182