# microsoft/winget-cli: the Windows Package Manager client and its PowerShell module > WinGet is Microsoft's package manager for Windows, shipped through the App Installer package and backed by the community winget-pkgs repository. This covers how to install it, how to use it from PowerShell, and where it stops being the right tool. **microsoft/winget-cli** — WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface). - Repository: https://github.com/microsoft/winget-cli - Website: https://learn.microsoft.com/windows/package-manager/ - Stars: 26,461 · Forks: 1,803 - Language: C++ - License: MIT - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-winget-cli ## What the WinGet client is for, and who ends up using it The Windows Package Manager is a tool for discovering and installing packages on a Windows PC. The README reduces the whole pitch to one line: `winget install `. That is the shape of the product. A user types one command and an application lands on the machine, without a browser download, an installer wizard, or a search through a vendor site. The repository is not the package catalog. It is the client: a C++ codebase that also exposes PowerShell modules and a COM API. The catalog side lives in the separate community repository, microsoft/winget-pkgs, which is one of two default sources the client talks to. The other is msstore, the Microsoft Store, limited in the client to free apps rated "e" for everyone. So the audience splits in two. Interactive users get a command line that behaves like apt or brew on Windows. Administrators and tool authors get the COM API and the Microsoft.WinGet.Client module, which is the more interesting half for anyone automating a fleet. The samples directory in the repository (ConnectionValidationSample, MinimalCallers, WinGetUWPCaller) points at that second audience: people writing code that calls into the client rather than typing at it. The licence is MIT, which is permissive and unremarkable here, but worth noting because the client source is genuinely open even though the recommended distribution channel is a Microsoft Store package. ## Sources, the COM API, and the shape of the codebase The client is built around the concept of sources, described in the README as "a set of packages effectively." Two are configured by default: winget for the community repository and msstore for the Store. That abstraction is what makes the client extensible in principle, and it is also where policy enters. The README warns that group policy may be configured and can modify the configured sources, and tells you to run `winget --info` to see any configured policies. If you are deploying this, that warning is the operational centre of the project. A machine can look broken to a user when in fact a policy removed a source. Architecturally, the repository layout tells you what you are adopting. src/ holds the client. schemas/ holds the manifest schemas, which matter if you publish packages rather than consume them. tools/ and templates/ support the packaging workflow. Localization/ signals that the client is shipped in many languages, which is typical for a first-party Windows component and adds review overhead to changes. The COM API is the integration surface for non-PowerShell callers; the PowerShell module wraps it for administrators who would rather not write C++ or COM interop by hand. The release cadence visible in the releases list is worth reading carefully. v1.29.290 is a stable release dated 2026-08-24, while v1.30.140-preview and v1.30.100-preview are preview builds from 2026-09-11 and 2026-08-13. The last push to the repository was on 2026-09-18. Preview and stable lines run side by side, so "latest release" is not a single answer on this project. ## Installing WinGet and running a first install The README states the client requires Windows 10 1809 (build 17763), Windows 11, Windows Server 2025, or later. Windows Server 2019 and 2022 can run it experimentally, not supported, by extracting the .msixbundle, and the README links issue 4502 for that path. Windows Server Core is out entirely, as are builds earlier than Windows 10 1809, because of hard dependencies on IsWow64Process2 and MSIX. The recommended channel is the Microsoft Store: the client is distributed inside the App Installer package. If you already have App Installer, you likely already have winget. The first thing to check is which policies are in force on the machine, because a configured source list changes what the commands below will find. ```bash winget --info ``` That prints the client version and any configured policies. If a source is missing or the client is not on PATH (an issue the README acknowledges some users have hit), fix that before troubleshooting anything else. For development releases there are three routes in the README: install a Windows 10 or Windows 11 Insider build, manually update from the Releases page, or use the `Repair-WinGetPackageManager` cmdlet from the Microsoft.WinGet.Client module with the `-IncludePrerelease` parameter. The README notes that a manual install from GitHub gives you the client but does not enable automatic updates from the Microsoft Store unless you have joined the Windows Package Manager Insider program. On older Windows 10 builds you may also need the VC++ v14 Desktop Framework Package, and only if you hit a missing framework package error. Once the client is present, the PowerShell module is a separate install from the PowerShell Gallery: ```powershell Install-Module -Name Microsoft.WinGet.Client ``` From there the README's example usage covers the common operations. These are cmdlets, not the winget executable, so they return objects you can pipe and filter, which is the reason to prefer them in scripts. ```powershell Find-WinGetPackage -Query "Visual Studio Code" Install-WinGetPackage -Id Microsoft.VisualStudioCode Get-WinGetPackage Update-WinGetPackage -Id Microsoft.VisualStudioCode Repair-WinGetPackageManager ``` `Find-WinGetPackage` searches, `Install-WinGetPackage` installs by identifier, `Get-WinGetPackage` lists what is installed, `Update-WinGetPackage` upgrades a specific package, and `Repair-WinGetPackageManager` repairs the manager's own installation. Note the identifiers: `Microsoft.VisualStudioCode`, not the display name. If you intend to build the client yourself, the README says that is possible and that the client should be functional, but full support for clients running outside the official distribution mechanisms is not there yet, and issues filed against such builds may get lower prioritization. That is an honest statement of scope and you should take it literally. ## Elevation, administrator prompts, and the failure mode nobody reads about The README's administrator section describes behaviour that catches people out. Run WinGet without administrator privileges and some applications will require elevation; Windows prompts, and if the user declines, the install fails. Run WinGet inside an Administrator Command Prompt and those elevation prompts do not appear at all. The install proceeds with whatever privileges the shell already has. That is a real failure mode, not a footnote. The absence of a prompt is not evidence that an installer is well behaved. It means the UAC gate was bypassed by the context you chose. The README's own advice is to be careful in an elevated prompt and only install applications you trust. For scripted deployment this matters more than for interactive use, because an unattended elevated run has no human in the loop at the moment the installer would otherwise have asked. The second limitation is platform reach. Windows Server Core cannot run the client at all, and Server 2019 and 2022 are explicitly experimental. If your fleet is Server Core, this is the wrong tool and no amount of configuration fixes it. If it is Server 2019 or 2022, you are on an unsupported path by the project's own description. The third is the PATH problem the README mentions: some users have reported the client not being on PATH after the App Installer update. A script that assumes `winget` resolves will fail intermittently across a mixed fleet. ## How WinGet differs from Chocolatey in practice The obvious comparison is Chocolatey, and the difference is not just command syntax. Chocolatey is a third-party package manager with its own community feed and a long history of packaging Windows software, including packages that wrap installers in PowerShell scripts maintained by the community. WinGet's client ships as part of Windows through App Installer, which means it arrives with the operating system rather than being something you install and then keep updated yourself. For a Windows administrator, that distribution difference is the whole argument: there is no bootstrap step on a machine that already has App Installer. The second difference is the sources model. WinGet's client is explicitly built around configurable sources, with the community repository and the Microsoft Store as defaults, and group policy able to modify them. That gives an organisation a lever to restrict what users can install without replacing the tool. Chocolatey's model centres on its own feed and its own server product for internal hosting. Both approaches let you host packages internally, but the control point sits in different places: policy and source configuration on one side, a separate server and feed on the other. Where Chocolatey still has an edge is reach. WinGet cannot run on Server Core and is experimental on Server 2019 and 2022, which are common server targets. If those are your machines, the comparison ends there regardless of feature lists. The README does not document rollback of an installed package, so if uninstall and rollback semantics are a deciding factor, verify them on your own workload before committing. ## Maintenance, upgrade paths, and what the MIT licence does not cover The repository is not archived and its last push was on 2026-09-18, three days before this writing, so the codebase is moving. Releases split into a stable line (v1.29.290, 2026-08-24) and a preview line (v1.30.140-preview, 2026-09-11; v1.30.100-preview, 2026-08-13). The README points at a release roadmap in the project's discussions, updated as the project proceeds, which is where the plan for the next release lives rather than in the repository itself. Upgrade cost depends on which channel you chose. If you installed through the Microsoft Store as recommended, updates arrive with the App Installer package and you do relatively little. If you installed a development build manually from the Releases page, the README is explicit that automatic Store updates are not enabled unless you joined the Windows Package Manager Insider program, so you own the upgrade loop. If you built the client yourself, you own it entirely, and the README says support for such builds is not fully there yet. Three channels, three very different maintenance bills, and the README does not pretend otherwise. The licence is MIT. That permits use, modification and redistribution with the licence and copyright notice preserved. It says nothing about the packages the client installs, which carry their own licences from their own publishers, and nothing about the Microsoft Store terms that apply to the recommended distribution channel. Those are separate questions from the client's source licence, and the repository does not answer them. ## Conclusion Adopt it on managed Windows 10 1809, Windows 11 and Windows Server 2025 fleets where a first-party client with a documented COM API and PowerShell module fits your tooling; skip it on Windows Server Core, on builds older than 1809, and on Server 2019 or 2022 if you need supported operation rather than the experimental .msixbundle extraction. Before rolling it out, run winget --info on a sample machine to see whether group policy has modified the configured sources, and confirm the target build number. ## FAQ ### How do I run the WinGet command? Install the client (it ships inside the App Installer package from the Microsoft Store), then run commands such as winget install from a command prompt. Run winget --info first to see the client version and any configured policies that may have modified your sources. ### Can I use WinGet in PowerShell? Yes. The Microsoft.WinGet.Client module installs from the PowerShell Gallery with Install-Module -Name Microsoft.WinGet.Client and provides cmdlets including Find-WinGetPackage, Install-WinGetPackage, Get-WinGetPackage and Update-WinGetPackage. ### Is it safe to use WinGet? The client is MIT licensed and the README notes that its default sources are the Microsoft Store (free apps rated "e") and the community winget-pkgs repository. The README's own caution concerns running an Administrator Command Prompt, where elevation prompts do not appear, so install only applications you trust. ### Is WinGet better than Chocolatey? They differ in distribution and control point. WinGet's client arrives with Windows through App Installer and is built around configurable sources that group policy can modify; Chocolatey is a third-party package manager with its own feed. WinGet cannot run on Windows Server Core and is experimental on Server 2019 and 2022. ### How do I install winget-cli? The recommended route is the Microsoft Store, where the client is distributed inside the App Installer package. Development builds are available from the Releases page, or via the Repair-WinGetPackageManager cmdlet with the -IncludePrerelease parameter. The client requires Windows 10 1809 (build 17763), Windows 11, Windows Server 2025, or later. ### What is winget-cli? It is the source repository for the Windows Package Manager client, written in C++, and it also includes PowerShell modules and a COM API. The client is built around the concept of sources, with the Microsoft Store and the community winget-pkgs repository configured by default. ## Sources - [License: MIT](https://github.com/microsoft/winget-cli/blob/master/LICENSE) - [microsoft/winget-cli on GitHub](https://github.com/microsoft/winget-cli) - [Project website](https://learn.microsoft.com/windows/package-manager/) - [README](https://github.com/microsoft/winget-cli/blob/master/README.md) - [Releases](https://github.com/microsoft/winget-cli/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-winget-cli