winget-install: a PowerShell installer for the WinGet package manager

A package manager that had no command line installer

The opening line of the README is a joke with a technical point inside it. WinGet, a command line package manager, does not have a command line installer, and the answer offered is that it does now.

The project is a PowerShell script, winget-install.ps1, that installs the WinGet client, and it is published as a package called winget-install on the PowerShell Gallery. The repository description spells out the promise: install WinGet using PowerShell, with prerequisites installed automatically, working on Windows 10, Windows 11 and Server 2019 and 2022. The homepage is a short link at bit.ly/winget-install.

The problem being solved is a bootstrap one. WinGet is distributed as an MSIX or MSIXBundle package, and installing it on a bare machine means dealing with the dependency packages the Microsoft.WinGet.Client package needs, which is a different story on each Windows release. The script's own feature list includes automatically determining and installing the appropriate prerequisites based on OS version, and always fetching the latest WinGet version.

Two version numbers tell you the pace. Releases 5.3.7 and 5.3.8 were both published on 2026-08-31, minutes apart, and 5.3.6 dates from 2026-01-12. The last push to the repository was on 2026-08-31, and the licence is GPL-3.0.

The supported operating systems are enforced, not assumed

The requirements section is specific, and the script checks them rather than hoping. It requires PowerShell running with Administrator privileges, or execution under the SYSTEM context, and it states which systems are compatible: Windows 10 at version 1809 or higher, Windows 11, Server 2019, 2022 and 2025, Windows Sandbox, and Server Core without the desktop experience, which is still under beta testing with details in issue 53.

Server 2016 and lower are listed as not compatible, because WinGet is not supported there.

That last point is the one to remember. The script's own functionality list says it checks the Windows OS version for compatibility, and on Windows 10 it additionally verifies the release id, which must be 1809 or newer. So a machine that is too old fails with a message rather than a half-installed package manager.

This matters most for the Server 2019 case, because that is the release where WinGet is not part of the operating system at all and has to be brought in from outside. For a fleet of build agents or lab machines on Server 2019, that difference is the whole reason a script like this exists.

One path for modern Windows, another for Server 2019

The script functionality section splits into two behaviours, and the split is the technical heart of the project.

On all operating systems except Server 2019, the script installs the NuGet package provider for PowerShell Gallery if it is not already present, installs the Microsoft.WinGet.Client package from the PowerShell Gallery, and then runs Repair-WinGetPackageManager -AllUsers, which is what actually installs WinGet and its dependencies and repairs problems along the way.

On Server 2019, that route is not available, so the script takes the manual path. It uses the UI.Xaml and VCLibs packages as recommended by Microsoft, downloads the WinGet-cli licence from the latest version on GitHub, installs the Visual C++ Redistributable if version 14 or higher is not already present, installs WinGet-cli from the latest GitHub version, and then adjusts access rights and the PATH environment variable.

Both branches finish with the same step: if the winget command is not detected at the end of the installation, the script runs command registration so the command actually resolves in a new shell.

The script also handles a few practicalities around the installation itself. It identifies the processor architecture to decide whether the x86/x64 or the arm/arm64 prerequisites are needed, it can automatically relaunch in conhost and end active processes associated with WinGet that could interfere with the installation, and it supports running under the SYSTEM context.

Three ways to run it, and only one takes parameters

The setup section documents three methods, and the recommended one is the PowerShell Gallery:

Install-Script winget-install -Force

The Gallery route is recommended because it always gets the public release that has been tested, it is easy to remember, and it supports all parameters. The -Force flag is optional but recommended, since it forces the script to update if it is outdated, and without it an outdated copy is not overwritten. Once installed, the script runs as:

winget-install

and -Force there means running the script even if WinGet is already installed.

The second method is a one line command that runs immediately, using the asheroto.com/winget short URL, which always redirects to the latest code-signed release of the script:

irm asheroto.com/winget | iex

The README is candid about the limitation of that form. Because of how PowerShell works, you cannot pass parameters such as -Force on that command line. The workaround is to set the global variable $Force to $true, which the script should pick up, and the parameters and global variables sections cover the cases where that does not work. The table of contents also lists a WinGet.pro short URL as a second option and a direct release URL as a third, with the local download and run method as the third method overall.

The hosted file is the code-signed release, and the source of that redirect is the releases page of the repository.

Parameters, global variables and version pinning

The parameter surface grew recently, and the what's new notes at the top of the README list the additions.

A GitHub API token can now be passed with -GHtoken, which the notes describe as improving reliability when checking for the latest WinGet version or when running into GitHub API rate limits. That is a straightforward fix for a real failure mode, since the script has to query GitHub for release information.

A specific WinGet version can be requested with -WingetVersion, and the note is precise about when that works: only when using -AlternateInstallMethod, which the note describes as the default method for Windows Server 2019. On every other platform the package path is used, and the version parameter has no effect there.

The -Force parameter and the $Force session variable do the same job from two directions, one as a command line argument and the other as a variable set in the session, and the one line command form can only use the variable.

Two global variables in the same family are documented, $Force being the one the README calls out explicitly, and the section on global variables exists because the piping form has no way to pass them otherwise. The trade-off for a user is that the parameterised path wants the Gallery or a local file, and the convenience path wants you to accept a remote script being executed with no options at all.

One script file, and a short link that tracks it

The repository is unusually small for a project of this kind. The top level contains .github/, .gitignore, LICENSE, README.md, SECURITY.md, an assets/ directory and a single PowerShell file, winget-install.ps1. There is no build system, no module manifest, no test suite directory and no packaging pipeline beyond the PowerShell Gallery publication.

That is a deliberate consequence of the design. The script is text that an administrator can read before running it, and the version that runs is the version in the repository. The assets directory holds the images used in the README, including the screenshot and the badge images.

The short link arrangement is worth noting as a design choice. asheroto.com/winget always redirects to the latest code-signed release, and the README says the same for the WinGet.pro short URL, with the direct release URL given as the third option. Redirecting to a release asset rather than to a branch means the link follows releases rather than the repository's head.

The security posture around that is the part to think about before pointing a fleet of machines at it. The script has a SECURITY.md in the repository, the published artefact is code signed, and the maintainer accepts sponsorship through GitHub Sponsors, Ko-Fi and Buy Me a Coffee, but none of that substitutes for reading winget-install.ps1 before piping it into iex on a production host.

Editorial conclusion

Adopt winget-install if you are provisioning Windows hosts, especially Server 2019 or Server 2025 boxes where WinGet is not present and the usual MSIX path is unavailable, and you would rather run one reviewed script than assemble the dependency chain yourself. Skip it if your machines already have the Microsoft.WinGet.Client package available, since the PowerShell Gallery route then adds a step for nothing. Before you run it, read the script at winget-install.ps1 rather than piping a remote file into iex, check that the host meets the Windows 10 version 1809 floor or the Server 2019 requirement, and note that Server Core remains under beta testing. The last push was on 2026-08-31 and release 5.3.8 was published the same day.

Frequently asked questions

Official sources

1. asheroto/winget-install on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases