Windows Package Manager
The Windows Package Manager, commonly referred to as winget, is a free and open-source package management system developed by Microsoft for Windows 10 (version 1809 and later) and Windows 11, enabling users to discover, install, upgrade, remove, and configure software applications through a unified command-line interface.[1][2] Introduced in preview at Microsoft Build 2020 on May 19 and reaching stable version 1.0 on May 26, 2021, the system automates software deployment and maintenance, drawing inspiration from cross-platform tools like those in Linux distributions while integrating natively with Windows ecosystems.[3][4] At its core, the Windows Package Manager comprises the winget command-line tool, which interacts with repositories such as the community-driven Windows Package Manager repository on GitHub and the Microsoft Store, allowing installations via simple commands likewinget install <package-name>.[5][2]
Supporting components include packaging services that use YAML-based manifests to define application metadata and installation instructions, as well as configuration files leveraging YAML and PowerShell Desired State Configuration (DSC) for automating device setups in enterprise environments.[1]
Key features emphasize security and flexibility, such as support for various installer formats including .msix, .msi, .exe, and even .zip archives; certificate pinning for trusted sources; and Group Policy integration on Windows 11 for administrative control over installations.[1][5]
As an open-source project licensed under the MIT License, it encourages community contributions for package submissions and enhancements, with ongoing releases—such as version 1.12, released in November 2025—adding capabilities like font management support and an MCP server for client configuration.[2][6]
Introduction
Overview
The Windows Package Manager, commonly known as Winget, is a free and open-source command-line package manager developed by Microsoft for discovering, installing, upgrading, removing, and configuring a wide range of applications on Windows 10 (version 1809 and later), Windows 11, and Windows Server 2025.[5][2] Winget facilitates automated software management through a centralized community repository, enabling users to streamline application lifecycle tasks from a single interface. It supports multiple package formats, including MSIX, MSI, and EXE installers, along with others such as APPX, ZIP, Inno Setup, and Nullsoft Scriptable Install System, allowing compatibility with diverse software distribution methods. Additionally, it integrates with the Microsoft Store as a default source and permits third-party repositories for expanded package availability. Built on the App Installer framework, Winget relies on YAML-formatted manifests to define package metadata, installation instructions, and dependencies, and is distributed via GitHub under the MIT license.[5][5][2] As of 2025, the official community repository hosts over 9,000 packages, reflecting significant growth in available software options. Winget is pre-installed on Windows 11 systems via the App Installer, enhancing its accessibility for end-users and enterprises seeking efficient package management.[7][5]Purpose and Adoption
The Windows Package Manager, commonly known as Winget, was developed to address the longstanding absence of a native, unified package management system in Windows, akin to tools like apt in Debian-based Linux distributions or yum in Red Hat systems. This gap often forced users to manually download installers from various websites, increasing exposure to untrusted sources and complicating software lifecycle management across discovery, installation, updates, and removal. Microsoft created Winget to streamline these processes, drawing from developer feedback and the need for a centralized, secure mechanism to handle application deployment on Windows 10 and later versions.[3] Winget offers significant benefits for both individual users and organizations by enhancing security through a curated repository with verification via SmartScreen filtering, static code analysis, and SHA256 hash validation, thereby minimizing risks from malicious software. It enables IT administrators to automate installations and updates, supports offline scenarios through the download command for exporting packages and dependencies, and integrates into DevOps workflows for scripting and continuous integration/continuous deployment (CI/CD) pipelines. These features reduce the time and effort required for software management compared to traditional methods, fostering more efficient environments for developers and enterprises.[3][8][9] Adoption of Winget has grown steadily since its stable release, with integration as the default component of the App Installer in Windows 11 starting from its initial launch in 2021, making it readily available without additional setup on modern Windows systems. In enterprise settings, it is widely used through Microsoft Intune for centralized application deployment and management, supporting scalable IT operations. The open-source nature has driven community involvement, with the winget-cli GitHub repository amassing over 25,000 stars and active contributions to the winget-pkgs repository, which hosts approximately 9,000 packages as of 2025. Developers have endorsed Winget for simplifying reproducible setups and accelerating onboarding in team environments, contributing to its role in modern Windows ecosystems.[5][7][2][7][10]History
Development Origins
The development of the Windows Package Manager, commonly known as Winget, originated from longstanding requests within the developer community for a native, Linux-inspired package management solution on Windows. Microsoft announced the project on May 19, 2020, during its Build developer conference, positioning it as a key addition to the Windows command-line ecosystem alongside tools like Windows Terminal.[3] This initiative addressed the absence of a unified system for discovering, installing, and managing software, drawing inspiration from established package managers such as apt and yum on Linux distributions, which had long been cited as a gap in Windows tooling.[3] The project was spearheaded by Microsoft's Windows Command Line team, with early contributions from engineers focused on enhancing developer productivity. The initial prototype leveraged the existing App Installer framework from the Microsoft Store, extending its capabilities to support command-line operations while introducing a new client for broader automation.[2] This approach allowed for rapid iteration, building on proven Windows deployment mechanisms like MSIX packages to ensure seamless integration without disrupting established workflows. Core design principles emphasized openness and flexibility from the outset, with the source code released under the MIT license to foster community involvement. The tool was engineered for cross-compatibility with various Windows application formats, including MSI, EXE, and MSIX, to accommodate diverse software ecosystems. Extensibility was a priority, enabling support for third-party repositories beyond Microsoft's default source, which encouraged collaborative manifest contributions via GitHub. An early emphasis on security included plans for package verification and safe installation practices to mitigate risks in downloading from community sources.[3] One of the primary early challenges involved reconciling Microsoft's proprietary Windows integrations—such as Store dependencies—with an open-source model to maintain accessibility and trust. This tension culminated in the public launch of the Winget CLI repository on GitHub on May 19, 2020, inviting global contributions and establishing a collaborative development path that aligned with Microsoft's evolving open-source commitments.[3]Release Milestones
The Windows Package Manager, commonly referred to as Winget, began with an initial preview release on May 19, 2020, announced during Microsoft Build to provide developers with an early tool for discovering, installing, and managing software packages via the command line. This preview version, labeled v0.1.41331, focused on basic functionality and community feedback, laying the groundwork for a standardized package management experience on Windows.[3] The stable v1.0 release arrived on May 26, 2021, marking a significant milestone by introducing core commands such as search, install, upgrade, and uninstall, while integrating with the official Windows Package Manager manifest repository hosted on GitHub, which debuted with over 1,400 verified packages from the community. This version stabilized the tool for broader adoption and was distributed through the Microsoft Store as part of the App Installer update for Windows 10 (version 1809 and later) and Windows 11.[4] Subsequent updates built on this foundation. Version 1.2, released on March 4, 2022, added export and import commands, allowing users to save installed package lists to a file and restore them on other machines, enhancing portability for development environments. In January 2023, v1.4 introduced support for ZIP-based packages alongside improved hashing mechanisms for better security and verification during installations.[11][12] Version 1.6, released in late 2023, enhanced enterprise capabilities with features like WinGet Configuration for declarative setup management and support for package dependencies, enabling more complex and automated deployment scenarios. Mid-2024 saw further refinements in v1.6 updates, including improved handling of silent installations to reduce user interruptions in scripted or automated workflows. By 2025, the tool had progressed to version 1.12, with the latest release, v1.12.420, issued on November 10, 2025, including servicing updates and performance optimizations.[13][14] At Microsoft Build 2025 in May, Microsoft announced enhancements to Winget as part of broader Windows developer tool improvements, emphasizing better integration for AI development workflows and increased productivity for package management. These updates have notably improved compatibility with enterprise tools like Microsoft Intune, facilitating wider adoption in organizational settings. The v1.0 stable release's repository integration remains a pivotal impact, fostering a growing ecosystem of community-contributed manifests now numbering around 9,000 packages as of October 2025.[15][7] Looking ahead, development continues actively on GitHub, with open issues exploring potential features for a future v2.0, including containerized application support and extensions for cross-platform compatibility to expand beyond traditional Windows environments.Technical Architecture
Core Components
The Windows Package Manager, commonly known as Winget, is primarily implemented as a command-line interface (CLI) tool built in C++ using a Visual Studio 2022 solution for its core client source code.[5] This runtime leverages .NET interop for certain operations, such as interactions with PowerShell modules, while relying on native Windows APIs for process elevation—prompting user consent via UAC when administrative privileges are required—and file handling during package operations.[16] The backend execution is handled through the Microsoft.DesktopAppInstaller package, which integrates Winget into the Windows App Installer framework and is distributed via the Microsoft Store for desktop updates or Windows Update for server environments.[5] Winget's execution model adopts a client-serverless architecture, where the CLI operates independently without a persistent local server, instead querying remote REST APIs from configured sources to retrieve package metadata in JSON format.[5] Upon user command, it downloads installers securely over HTTPS, supporting various formats including MSI, MSIX, EXE, and ZIP, and executes them with predefined parameters specified in package manifests to ensure consistent installation behaviors like silent mode or custom switches.[17] This model enables efficient, on-demand operations without requiring a central daemon, though it may reference external repositories like the community source for discovery.[2] Integration points extend Winget's functionality into the broader Windows ecosystem. It supports scripting via an official PowerShell module (Microsoft.WinGet.Client) for programmatic control and automation of package management tasks.[18] Additionally, Winget exposes configuration options through the Windows Settings app under the App Installer section for user-friendly tweaks, and via the settings.json file for customizing paths and behaviors.[19] Security features are embedded throughout the runtime to mitigate risks, including verification of package signing for supported formats like MSIX to confirm publisher authenticity, and SHA256 hash validation of downloaded installers against manifest values to prevent tampering or substitution attacks.[20] These mechanisms collectively ensure that operations remain secure by default, with optional overrides available only under elevated privileges.Package Sources and Repositories
The official repository for the Windows Package Manager, known as the Microsoft Community Package Manifest Repository, is hosted on GitHub at microsoft/winget-pkgs and serves as the default source for package manifests.[21] This open-source repository contains YAML manifest files for thousands of applications, supporting installers in formats such as MSIX, MSI, APPX, and .exe, with over 30,000 manifests as of September 2025.[22] It is maintained through community contributions submitted via pull requests, which undergo a validation process to ensure quality, including checks for manifest syntax, metadata accuracy, and installer integrity before merging.[23] Winget supports additional package sources beyond the official repository, including custom repositories exposed via REST endpoints, which allow organizations to host private or enterprise-specific feeds for controlled application distribution.[24] A reference implementation for creating such REST-based sources is provided by Microsoft on GitHub.[25] Integration with the [Microsoft Store](/page/Microsoft Store) is also available through the msstore source, enabling installation of Store apps alongside traditional desktop software.[5] While direct bridges to third-party managers like Chocolatey are not native, custom REST sources can incorporate manifests from such ecosystems for hybrid usage.[26] Each manifest in these repositories includes essential metadata, such as the package version, installer download URLs, and SHA256 hashes for integrity verification.[27] During installation, Winget downloads the installer and computes its hash to match the one specified in the manifest, preventing tampering or corruption; this process relies on hash validation rather than mandatory digital signatures for all packages, though signed installers from trusted publishers enhance security.[28] Winget includes source management features, such as package pinning to restrict upgrades to specific version ranges. Offline capabilities are supported through manual downloading of installers and manifests via thewinget download command, allowing operations in disconnected environments after initial preparation.[29][30] These features support enterprise scenarios by enabling more granular control over source prioritization and reducing dependency on constant network access.[7]
Installation and Setup
System Requirements
The Windows Package Manager, known as Winget, requires Windows 10 version 1809 (build 17763) or later, Windows 11, or Windows Server 2025 to operate, with support limited to the x64 architecture; ARM64 compatibility remains experimental and may encounter installation or package execution issues as of 2025.[5][31][32] On the hardware side, Winget imposes minimal demands, aligning closely with baseline Windows requirements: a 1 GHz or faster processor, at least 1 GB of RAM, and approximately 20 MB of free disk space for the tool itself, though additional space is needed for downloaded packages. An active internet connection is essential for initial source synchronization, package discovery, and downloads from repositories like the Microsoft Community Store.[5] Key dependencies include elevated administrator privileges for system-wide installations, as user-context execution limits access to certain applications that require broader permissions. While Winget itself does not mandate .NET Framework 4.8 or .NET 6+, advanced scripting or integration scenarios may leverage these for custom automation; Microsoft Edge WebView2 is optionally required for graphical interfaces in the associated App Installer, but not for core CLI functionality.[5] Prior to 2025 updates, Winget was distributed via the separate App Installer package from the Microsoft Store, necessitating manual installation on eligible systems; starting with Windows 11 builds and Windows Server 2025, it is included by default, with enhanced features like improved source management requiring the latest Windows updates for full compatibility.[5][33]Installing Winget
Winget, the client for the Windows Package Manager, is pre-installed on Windows 11 starting from version 21H2 and later, as well as on Windows Server 2025 through system updates.[5] On Windows 10 version 1809 (build 17763) and later, it is included in the App Installer package from the Microsoft Store, requiring the latest version of the App Installer from the Microsoft Store for full functionality; users can download and install it directly from the Store if not present.[5] For manual installation on supported systems, download the latest.msixbundle file from the official GitHub releases page.[6] Double-click the downloaded bundle to install it via the standard MSIX process, or use PowerShell as an administrator with the command Add-AppxPackage -Path "path\to\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle" after ensuring dependencies like Microsoft.VCLibs are installed (e.g., via Add-AppxPackage -Path "https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx").[34] If Winget is already provisioned but not registered, run Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe in an elevated PowerShell prompt to activate it without redownloading.[5] For enterprise environments without Microsoft Store access, such as Windows Server or LTSC editions, the .msixbundle method is recommended, with support for Desired State Configuration (DSC) in Winget version 1.11 and later to automate deployments.[6]
After installation, verify Winget by opening Command Prompt or PowerShell and running winget --version, which displays the installed version (e.g., 1.12.420 as of November 2025).[5] For initial configuration, execute winget settings to open the JSON settings file in a default editor like Notepad; here, users can customize package sources (e.g., set "source": {"autoUpdateIntervalInMinutes": 0} to disable automatic updates) or disable telemetry (e.g., "telemetry": {"disable": true}).[19] To check for and apply updates to installed applications, including Winget itself if sourced appropriately, use winget upgrade --all; Winget updates are typically handled automatically via the Microsoft Store on consumer editions.[35]
Common troubleshooting issues include User Account Control (UAC) prompts during machine-scope installations, which require administrator privileges—run commands in an elevated prompt to avoid interruptions.[36] Proxy-related problems can occur in networked environments; configure HTTP proxy support by setting environment variables like HTTP_PROXY and HTTPS_PROXY before running Winget commands, with enhanced proxy handling added in 2025 updates for better enterprise compatibility.[37] For diagnostics, use winget --open-logs to access log files in %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir, or enable verbose logging in the settings file with "logging": {"level": "verbose"}.[36] On systems like Windows 11 24H2, ensure optional features are enabled via Windows Update if Winget appears unavailable post-deployment.[5]
Basic Usage
Command Structure
The Windows Package Manager, commonly known as Winget, follows a consistent command-line syntax to ensure predictable usage across its operations. The basic structure iswinget <command> [<options>] [<arguments>], where <command> specifies the primary action such as install or search, <options> are flags modifying behavior (prefixed with -- or -), and <arguments> include positional inputs like package queries.[5] This format allows for chaining subcommands in some cases, such as winget source list, and supports aliases for brevity, like add for install. Global options applicable to most commands include --help to display usage information, --version to show the client version, --verbose or --verbose-logs for detailed output, --silent to suppress interactive prompts, --accept-package-agreements to automatically accept license agreements during installations, and --accept-source-agreements to bypass source-related confirmations.[5][17][8]
Package identifiers serve as key arguments for targeting applications and can take forms such as the full ID (e.g., Microsoft.PowerToys), name (e.g., PowerToys), or moniker, often combined as Id.Name for precision. Wildcards (*) enable partial matching in queries, while the --exact option enforces strict string matches to avoid ambiguities. Scope options like --scope user or --scope machine determine whether operations apply to the current user or all users on the system, with machine-wide actions typically requiring elevated privileges.[17][38][39]
Error handling in Winget relies on exit codes returned by commands, where 0 indicates success and non-zero values (e.g., 1 for general errors) signal failures such as invalid arguments or network issues. Users can query descriptions for specific codes using winget error <code>, and detailed diagnostics are logged to %LOCALAPPDATA%\Packages\[Microsoft](/page/Microsoft).DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir, with up to 100 files retained and older ones rotated out. The --logs or --open-logs options provide quick access to this directory post-execution.[36][40]
Winget incorporates user-friendly conventions to enhance interactivity and automation. Tab completion is supported in PowerShell by registering an argument completer script in the user's profile, enabling context-aware suggestions for commands, options, and package names upon pressing Tab; Command Prompt offers basic completion through the tool's built-in capabilities. For scripted or machine-readable output, certain commands like list and search support the --output json flag to format results in JSON instead of the default table view, facilitating integration with tools like PowerShell or external parsers.[41][39][38]
Common Commands
Thewinget search command allows users to discover available packages by querying for applications using a name, identifier (ID), or tag, returning a tabular output that includes columns for Id, Name, Version, and Source.[38] The syntax is winget search [[-q] <query>] [<options>], where the -q or --query argument provides the search term for case-insensitive substring matching across relevant fields.[38] Key options include --exact for precise case-sensitive matches, --count <number> to limit results (up to 1000), --id to filter by application ID, --name to filter by name, and --tag to filter by tags, enabling targeted discovery without installing.[38]
The winget install command downloads and executes the installer for a specified package, supporting interactive or silent modes based on user preferences.[17] Its syntax is winget install [[-q] <query> ...] [<options>], with the -q or --query argument identifying the package via an exact ID or search term that prompts for disambiguation if needed.[17] Notable options encompass --override "<arguments>" to pass custom parameters to the installer (e.g., "/silent" for unattended installation), --location <path> to specify a custom installation directory when supported by the package, and -a or --architecture to select variants like x64 or arm64, accommodating diverse system configurations.[17]
The winget list command enumerates all applications installed on the system, including those managed by Winget or other methods, and can highlight available updates.[39] The basic syntax is winget list [[-q] <query>] [<options>], where omitting arguments displays a comprehensive inventory, while --upgrade-available filters to show only packages with updates.[39] Filtering is achieved via options such as --source to restrict by repository (e.g., winget or msstore), --include-unknown to incorporate unverified sources, or --id and --name for specific targeting; output can be redirected to formats like JSON or YAML for scripting purposes, such as winget list > packages.json.[39]
The winget upgrade command updates installed packages to their latest versions, either individually or in bulk, by leveraging the same installer mechanisms as installation.[35] Syntax follows winget upgrade [[-q] <query> ...] [<options>], with --all upgrading every eligible package and --uninstall-previous ensuring prior versions are removed during the process if required by the package.[35] Options like --id, --name, --silent, and --interactive mirror those in install for controlled execution, allowing users to preview updates via winget list --upgrade-available beforehand.[35]
The winget uninstall command removes specified applications, requiring an exact identifier to avoid unintended deletions.[42] Its syntax is winget uninstall [[-q] <query>] [<options>], supporting --force to bypass non-critical errors during removal and --purge for portable packages to delete all associated files and directories.[42] Additional controls include -v or --version for targeting specific versions, --all-versions to remove multiples, and --silent for non-interactive uninstallation, ensuring safe and precise package management.[42]
As of 2025, the winget configure command facilitates automated environment setup by applying declarative configuration files, streamlining machine provisioning for development or standardized deployments.[43] The primary syntax is winget configure -f <path-to-config-file.dsc.winget>, where the file (in .dsc.winget format) defines resources like packages, settings, and processes to install or configure.[43] Subcommands such as show for previewing files, test for compliance checks, and export for generating configurations from existing systems enhance reproducibility, with support requiring Winget version 1.6.2631 or later on Windows 10 build 17763+.[43]
Advanced Features
Configuration Management
The Windows Package Manager, known as Winget, allows users to customize its behavior through a settings file located at%LOCALAPPDATA%\Microsoft\WinGet\Settings\settings.json. This JSON file, which follows a schema defined at https://aka.ms/winget-settings.schema.json, enables configuration of various aspects such as telemetry, source updates, and installation preferences. For instance, telemetry can be disabled by setting "telemetry": { "disable": true } to prevent data collection on usage patterns. Installation behaviors can also be adjusted, including preferences for scope (user or machine), locale, and architectures, as in "installBehavior": { "preferences": { "scope": "machine" } }.[19]
Declarative configurations in Winget facilitate repeatable and idempotent machine setups by defining desired package states in YAML files, a feature that supports consolidated onboarding for development environments. These configuration files specify packages to install, update, or remove, along with settings for behaviors like silent installation or scope. Users apply such files using the winget configure command, for example, winget configure --file configuration.yaml, ensuring consistent application across machines without manual intervention. This capability, enhanced in updates through 2025, integrates with tools like Desired State Configuration for automated deployments.[44][43]
Environment management in Winget involves handling package sources and network settings to tailor repository access and reliability. Sources can be added or pinned for custom repositories with commands like winget source add --name Custom https://api.url/v1/manifests, allowing prioritization of specific feeds over defaults. To restore default sources, winget source reset --force clears custom additions and refreshes the environment. Proxy configurations are supported via standard environment variables such as HTTP_PROXY and HTTPS_PROXY, enabling Winget to route requests through corporate networks without additional tool-specific setup.[24]
Best practices for Winget configuration emphasize stability and verification to support production environments. Version pinning in declarative configurations or via winget pin add --id PackageId --version 1.2.3 prevents unintended auto-upgrades that could introduce breaking changes, ensuring predictable behavior in scripted setups. Additionally, validating configurations before deployment using winget configure validate -f configuration.yaml checks for syntax errors and resource compatibility, reducing deployment failures. These approaches promote idempotency and minimize disruptions in repeatable installations.[29][43]
Enterprise Integration
The Windows Package Manager, known as Winget, integrates seamlessly with Microsoft's enterprise management tools to facilitate policy-driven application installations and updates across large-scale environments. Through Microsoft Intune, administrators can deploy Winget as a Line-of-Business app using .msixbundle packages, enabling automated scripting for upgrades such aswinget upgrade --all via PowerShell in Intune's Platform Scripts feature.[45] Similarly, integration with Microsoft Endpoint Configuration Manager (formerly SCCM) allows for centralized distribution of Winget packages, supporting compliance enforcement and reporting in hybrid environments.[46] Recent enhancements in Windows builds, including those aligned with 2025 updates, extend Winget functionality to Entra ID (formerly Azure AD) joined devices, allowing policy-based management without additional configuration on managed endpoints.[45]
For automation in enterprise workflows, Winget supports PowerShell scripting through the official Microsoft.WinGet.Client module, available on the PowerShell Gallery, which provides cmdlets like Get-WinGetPackage and Install-WinGetPackage for programmatic installation and management of applications.[5] This module enables integration into CI/CD pipelines, where GitHub Actions can automate manifest validation using the winget validate command to ensure package integrity before submission to repositories.[47] Additionally, for air-gapped or offline networks, Winget offers the download command to retrieve installers for local distribution, supporting disconnected servicing scenarios common in high-security enterprises.[48]
Policy enforcement is achieved via Group Policy templates under Computer Configuration > Administrative Templates > Windows Components > Windows Package Manager, allowing administrators to disable telemetry by setting the telemetry.disable option to true, thereby preventing ETW event logging to Microsoft.[19] Sources can be restricted using policies like "Allowed Sources," which limit installations to approved repositories such as the default Winget community source or Microsoft Store, enhancing control in regulated environments.[49] For compliance reporting, the winget export command generates JSON files listing installed applications and versions, which can be integrated into Endpoint Configuration Manager for auditing and log aggregation across endpoints.[50]
In terms of enterprise security, Winget maintains compatibility with AppLocker through configurable policies that allow or deny executions based on publisher rules, ensuring it operates within existing application control frameworks.[51] Centralized certificate trust is supported via Windows' native trust store, with Winget verifying signatures during downloads and installations to mitigate risks from untrusted sources. Case studies from enterprise adopters demonstrate practical impacts, such as one organization reducing software maintenance time by 85% across 500 endpoints through automated Winget updates, highlighting its efficiency in scaling deployments for over 1,000 devices.[52]
Package Manifests
Structure and Format
The Windows Package Manager, commonly known as Winget, relies on YAML-formatted package manifests to define metadata for software installation, including identifiers, versions, and installer details. These manifests adhere to a structured schema that ensures consistency and validation across the ecosystem. The schema specifies root-level keys and nested sections, primarily using PascalCase for field names, with string lengths limited to 100 characters to maintain compatibility.[53] At the root level, key fields includePackageIdentifier (in the format Publisher.PackageName, required for unique identification), PackageVersion (the software's version string, required), PackageLocale (BCP 47 language code like en-US, required for locale-specific files), Publisher (the developer's name, required), PackageName (the application's display name, required), License (the license type or URL, required), ShortDescription (a brief overview, required), ManifestType (such as "version" for updatable packages or "singleton" for one-time installs, required since version 1.0), and ManifestVersion (the schema version, e.g., 1.6.0 or later, required). Optional fields like DefaultLocale support multi-locale manifests by specifying a primary language. The Installers array is a core section containing one or more installer objects, enabling support for different architectures or scopes.[53]
Within the Installers section, each object details installation specifics, including Architecture (e.g., x64 or arm64, required), InstallerType (e.g., exe, msi, or msix, required), InstallerUrl (the download location, required), InstallerSha256 (the file's hash for integrity verification, required), and ProductCode (for MSI packages, to enable upgrades). Additional fields like InstallerSwitches allow customization of silent installation arguments (e.g., /silent for quiet mode, optional), while MinimumOSVersion specifies the lowest supported Windows version (e.g., 10.0.19041.0, optional but used to restrict compatibility). The DefaultInstall key at the root can reference an index into the Installers array to designate a preferred option. These elements ensure secure and automated deployments without user intervention.[53][54]
Validation of manifests follows the JSON schema equivalent (YAML is parsed accordingly), enforcing required fields and data types; incomplete or malformed files, such as missing hashes or invalid locales, are rejected during processing. Tools like YAML linters or the official winget validate command check compliance, with multi-file manifests (e.g., separate version and locale files) requiring all components for completeness. The schema has evolved from its initial 1.0 release pre-2023, which emphasized single-installer setups, to versions like 1.12 (as of November 2025), incorporating multi-architecture support, multiple installer options, and new types such as Font and NestedInstallerType for broader package coverage.[53][55]
For illustration, a minimal singleton manifest might appear as follows:
This structure partitions manifests for repository hosting, such as the community-driven winget-pkgs on GitHub.[53]yamlPackageIdentifier: Example.Publisher.App PackageVersion: 1.0.0 PackageLocale: en-US Publisher: Example Publisher PackageName: Example App License: [MIT](/page/Mit) ShortDescription: A sample application. ManifestType: [singleton](/page/Singleton) ManifestVersion: 1.12.0 Installers: - Architecture: [x64](/page/Architecture) InstallerType: [exe](/page/.exe) InstallerUrl: [https://example.com/installer.exe](/page/HTTPS) InstallerSha256: ABC123... InstallerSwitches: Silent: /silent SilentWithProgress: /quiet MinimumOSVersion: 10.0.19041.0PackageIdentifier: Example.Publisher.App PackageVersion: 1.0.0 PackageLocale: en-US Publisher: Example Publisher PackageName: Example App License: [MIT](/page/Mit) ShortDescription: A sample application. ManifestType: [singleton](/page/Singleton) ManifestVersion: 1.12.0 Installers: - Architecture: [x64](/page/Architecture) InstallerType: [exe](/page/.exe) InstallerUrl: [https://example.com/installer.exe](/page/HTTPS) InstallerSha256: ABC123... InstallerSwitches: Silent: /silent SilentWithProgress: /quiet MinimumOSVersion: 10.0.19041.0
Creating and Publishing
Creating and publishing package manifests for the Windows Package Manager involves authoring YAML files that describe software installers, validating them for compliance, and submitting them to the community repository for review and integration. Authors typically use tools like Visual Studio Code with a YAML extension for manual editing or the official WingetCreate command-line tool to automate manifest generation.[53][56] To author a manifest, developers first gather essential details such as the installer's download URL and its SHA256 hash to ensure integrity during installation. They then define key metadata fields, including the package identifier, version, publisher, name, license, and a short description, following the YAML schema outlined in the official specification. For automation, install WingetCreate viawinget install wingetcreate and run wingetcreate new to prompt for these details and generate the file; alternatively, use the YAMLCreate.ps1 PowerShell script from the repository's Tools folder for similar functionality. Once created, test the manifest locally by executing winget install --manifest file.yaml to verify that the package installs correctly without errors.[53][56][57]
Validation ensures the manifest adheres to repository policies and avoids issues like duplicates. Use the winget validate --manifest file.[yaml](/page/YAML) command to check schema compliance, policy violations, and structural errors before submission. Additionally, search the community repository for existing packages with the same identifier to prevent conflicts.[47][23]
The publishing workflow centers on the open-source GitHub repository at microsoft/winget-pkgs. Fork the repository, add the validated manifest to the appropriate folder under manifests/ (e.g., manifests/p/Publisher/PackageName/Version/), commit the changes, and create a pull request (PR) detailing the submission. Automated validation runs on the PR, followed by manual review from maintainers to confirm quality and security; approved PRs are merged, triggering automatic building and indexing for availability via winget.[23][21]
Best practices include proper version management by incrementing the package version in both the manifest and the repository folder path to reflect updates accurately. Maintain clear commit messages or PR descriptions as informal changelogs to aid reviewers, and ensure all installer hashes are correctly computed to uphold package integrity.[23][58]
Examples
Installation Examples
The Windows Package Manager, commonly referred to as Winget, provides straightforward commands for installing applications from its repository. A simple installation can be performed by specifying the package name or identifier directly. For example, executingwinget install [Google.Chrome](/page/Google_Chrome) downloads and installs the latest stable version of Google Chrome from the Winget source, prompting for user confirmation unless silent mode is enabled via options like --silent.[17][59]
For installations that do not require administrative privileges, Winget supports user-scoped deployment. The command winget install --id Python.Python.3 --scope [user](/page/User) installs Python version 3 for the current user only, placing files in the user's profile directory and avoiding system-wide changes or elevation prompts.[17]
Batch installations allow multiple packages to be specified in a single command for efficiency. Running winget install --id 7zip.7zip --id VideoLAN.VLC sequentially downloads and installs both 7-Zip and VLC media player, processing each package in order and displaying individual progress for each.[17][60][61]
In interactive scenarios, users may first search for available packages to identify exact identifiers or versions. For instance, winget search vlc lists matching results, such as VideoLAN.VLC, enabling a refined installation like winget install --id VideoLAN.VLC --location C:\CustomApps to override the default path if the installer supports it.[38][17]
Winget outputs include progress indicators, such as download bars and installation status messages, to track the process in real-time. If user prompts arise for licenses or confirmations, they must be acknowledged unless suppressed with --accept-package-agreements; successful completions display a summary like "Successfully installed," while failures log details to %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir for verification.[17]
Update and Management Examples
Thewinget upgrade --all --include-unknown command enables comprehensive updating of all installed packages managed by Winget, including those with unknown current versions that might otherwise be skipped during routine checks.[35] This option is particularly useful for system maintenance, as it scans the Winget source repository for the latest available versions and applies upgrades automatically, ensuring applications remain current without manual intervention for each one. For instance, running this command in an elevated Command Prompt or PowerShell session will prompt for confirmation on each update unless combined with silent installation flags, helping administrators keep environments up to date across multiple machines.[35]
For targeted updates, the selective upgrade syntax winget upgrade --id Microsoft.VisualStudioCode allows users to focus on a specific application by its unique identifier, bypassing the need to upgrade everything at once.[35] This approach is efficient for scenarios where only certain tools require immediate attention, such as patching a frequently used editor without disrupting other software. To suppress interactive notifications during the process, options like --silent can be appended, enabling scripted or automated executions that minimize user disruption while still applying the update.[35]
Inventory management is facilitated by the winget export > installed.json command, which exports a detailed list of all installed applications in JSON format for easy parsing and storage.[50] This output includes package names, IDs, versions, and sources, making it ideal for creating backups of software configurations or conducting audits to verify compliance in enterprise settings. By using the related winget list --upgrade-available command, users can generate reports specifically highlighting outdated packages, streamlining the identification of maintenance needs without sifting through full logs.[39]
Uninstallation is handled via commands like winget uninstall --id Adobe.Acrobat.Reader.64-bit --force, which removes the specified application even if minor issues arise, such as dependency conflicts.[42] The --force option overrides non-critical errors, ensuring the process completes reliably, while combining it with --purge facilitates thorough data cleanup by deleting residual files and directories associated with the package.[42] This is especially beneficial for reclaiming disk space after decommissioning unused software, as it goes beyond basic removal to eliminate portable app remnants that might persist otherwise.
In practical scenarios, automating weekly updates via a scheduled script enhances ongoing maintenance; for example, a PowerShell script invoking winget upgrade --all --include-unknown can be configured as a Windows Task Scheduler job to run silently during off-peak hours.[62] This setup ensures consistent patching without manual oversight, reducing vulnerability exposure across devices.[63]