Build winget commands to search, install, upgrade and uninstall Windows apps.
winget is the Windows Package Manager: a command-line client that installs, updates and removes applications from a curated repository, without visiting a download page or clicking through an installer. This builder writes the command for the action you pick — search, install, upgrade one, upgrade all, uninstall, list, show, export or import — and adds the flags you tick. It generates text in your browser and nothing else; you run the command yourself.
The command that gets used more than any other:
winget upgrade --all --include-unknown --silent --accept-source-agreements --accept-package-agreements
That updates everything winget can see, does not stop to ask about licence agreements, and includes the applications whose currently installed version it cannot determine. Run it in an elevated prompt if any of the applications are installed machine-wide.
Every install, upgrade, uninstall and show command in this builder uses --id. That matters, because the alternative is worse. A bare winget install vlc searches names, IDs and monikers, and if more than one package matches, winget refuses to proceed and tells you the query returned multiple results. Worse, if exactly one package matches loosely, it installs that — which may not be the one you meant.
Package IDs are stable, unambiguous identifiers in Publisher.Application form: VideoLAN.VLC, Microsoft.PowerShell, Git.Git, Mozilla.Firefox. Find the exact one first:
winget search "vlc"
Read the ID column, then use it. Add -e — the short form of --exact, which the builder ticks by default — and matching becomes exact and case-sensitive rather than a substring search. Without it, --id Microsoft.PowerShell also matches Microsoft.PowerShell.Preview. With it, you get precisely the package you named or a clean failure. A clean failure is much better than the wrong package installed silently.
| Action | Command the builder writes | Notes |
|---|---|---|
| Search | winget search "term" | Your starting point. Searches all configured sources |
| Install | winget install --id Publisher.App -e --silent | Optionally pinned to a version and a scope |
| Upgrade one | winget upgrade --id Publisher.App -e --silent | Fails harmlessly if no newer version exists |
| Upgrade all | winget upgrade --all --include-unknown --silent --accept-source-agreements --accept-package-agreements | Reviews nothing — think before running on a server |
| Uninstall | winget uninstall --id Publisher.App -e | Runs the app’s own uninstaller; may leave settings behind, may delete data |
| List installed | winget list | Shows everything in Add/Remove Programs, not only winget-installed apps |
| Show details | winget show --id Publisher.App -e | Version, publisher, licence, installer type and download URL — without installing |
| Export | winget export -o packages.json | Writes a JSON manifest of installed packages |
| Import | winget import -i packages.json --accept-package-agreements --accept-source-agreements | Installs everything in that manifest on another machine |
-e / --exact — exact, case-sensitive matching against the ID. Leave it on.--silent — passes the installer’s own quiet switch so no setup wizard appears. Not universal: a package whose manifest does not define a silent switch will still show its installer, and there is nothing winget can do about that.--version — installs a specific version rather than the newest. Essential when a build tool or driver must match something else, and the reason the version box exists on the install action. The version must be one the source actually carries; winget show --versions --id <id> lists them.--scope user / --scope machine — install for the current user only, or for all users. Machine scope needs elevation. Many packages support only one of the two, and asking for the unsupported one produces “no applicable installer found”, which reads like the package is missing when it is not.--include-unknown — without this, upgrade --all silently skips any application whose installed version winget cannot read. That is a surprisingly large share of them, and it is why people report that upgrade-all “did not do anything”. The builder ticks it by default.--accept-source-agreements and --accept-package-agreements — suppress the interactive agreement prompts that would otherwise stall an unattended run. The builder adds both to upgrade-all and to import for exactly that reason.A stock installation has two sources configured. winget is the community repository of manifests, and it is where nearly everything you install from the command line comes from. msstore is the Microsoft Store catalogue, which can require accepting additional terms and sometimes a signed-in account.
The builder does not emit a source flag, so commands run against all configured sources. When a name exists in both catalogues you will get a multiple-results error, and the fix is to restrict the search yourself:
winget install --id VideoLAN.VLC -e --source winget
Other source commands you type by hand: winget source list to see what is configured, winget source update to refresh the local index when a package you know exists is not being found, and winget source reset --force as a last resort when the index is corrupted.
If one application must stay where it is — a build toolchain your project depends on, a driver utility, a version your vendor certified — then a blanket upgrade --all is a hazard. Pinning is the answer, and it is a separate command family the builder does not generate:
winget pin add --id Publisher.App — pin the package so upgrade --all skips it while still reporting that a newer version exists.winget pin add --id Publisher.App --blocking — a stronger pin that blocks even an explicit winget upgrade for that package unless you override it.winget pin list — show every pin currently in place. Worth running before you wonder why something is not updating.winget pin remove --id Publisher.App — lift the pin.Pin first, then run upgrade-all with confidence. That combination is what makes the one-line update command safe enough to use on a machine that matters.
winget export -o packages.json writes a manifest of the installed packages winget recognises, and winget import -i packages.json reinstalls them elsewhere. It is the closest thing Windows has to a portable application list, and it is genuinely useful when setting up a replacement laptop.
Two honest limits. Export only records applications that map to a package in a configured source — anything installed from a vendor’s own MSI, an internal line-of-business app, or a Store app with no winget manifest is left out, so treat the file as a good start rather than a complete inventory. And by default the manifest records package identity, not exact versions; add --include-versions to the export if reproducing precise versions matters. Import skips packages that are already present, so it is safe to re-run.
| Symptom | Cause and fix |
|---|---|
| “winget is not recognised” | App Installer is missing or out of date. Install or update App Installer from the Microsoft Store, then open a new terminal — the PATH change does not reach sessions already open |
| Multiple packages found matching the input criteria | Your query is ambiguous. Use --id with -e, and add --source winget if the name exists in both catalogues |
| No applicable installer found | Usually a scope or architecture mismatch — try without --scope, or check winget show for what the package actually provides |
| upgrade --all reports nothing to do, but apps are clearly out of date | Missing --include-unknown, or the apps are pinned, or they were installed by a mechanism winget cannot version |
An installer window appears despite --silent | That package’s manifest defines no silent switch. Nothing to fix at your end |
| Install fails only when not elevated | Machine-scope installs require administrator rights. Use an elevated prompt, or --scope user if the package supports it |
winget list shows entries with GUID-style IDs | Those came from Add/Remove Programs and have no winget manifest. winget can often uninstall them but cannot upgrade them |
| A package you know exists is not found | Stale local index — run winget source update |
Start with winget search, copy the exact ID, keep -e on, pin anything that must not move, and the rest of Windows software management collapses into one line you can paste into a script.
The builder covers the options most people change. Several others are worth knowing and are typed by hand: --interactive forces the installer’s own UI when you need to make choices during setup, --override passes a raw argument string straight to the underlying installer, --location sets an install directory for packages that support one, and --force pushes past certain hash and applicability checks — use that last one sparingly, since the hash check is what tells you the download matches the manifest.
Automation has one gotcha that costs people a lot of time. winget ships as part of App Installer, which is an MSIX package registered per user, so it is generally not available in the SYSTEM context that device-management platforms and startup scripts run under. A command that works perfectly in your own elevated terminal can fail with “winget is not recognised” when the same line is deployed as a SYSTEM-context script. The usual workarounds are to invoke the resolved path to the packaged executable, or to run the deployment in the user context instead. Test the command in the context it will actually run in, not in your interactive session.
Two smaller notes for scripted use. winget upgrade with no arguments simply lists what has updates available, which makes it a safe read-only check to run before the destructive version. And winget list --id Publisher.App -e is a clean way for a script to test whether a specific package is present, without parsing the full inventory.
winget is the Windows Package Manager, a built-in command-line tool on Windows 10 (1809 and later) and Windows 11. It installs, upgrades, and removes applications from a curated catalog so you can manage software without manual downloads or setup wizards.
Run winget upgrade --all to update everything winget can see. Add --include-unknown to also catch apps whose current version it cannot detect, and the accept-agreement flags to run fully unattended without license prompts.
Use winget install --id Publisher.App -e --silent. The -e flag forces an exact ID match so you get the right package, and --silent suppresses the installer interface and prompts, which is ideal for scripts and remote deployment.
Yes. Run winget export -o packages.json on the old machine to save a manifest of installed packages, then winget import -i packages.json on the new one to reinstall the whole list in a single command.