winget-pkgs Documentation

Technical Documentation: microsoft/winget-pkgs

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (README.md)

Windows Package Manager Community Repository

This repository contains the manifest files for the Windows Package Manager default source. You are highly encouraged to submit manifests for your favorite application.

[!IMPORTANT]
At this time installers must be MSIX, MSI, APPX, MSIXBundle, APPXBundle, or .exe application installers. Font files (.ttf, .ttc, .otf, .otc, and .fnt) are also supported, although we are not currently accepting community submissions for these yet. Script-based installers are not currently supported.

The Windows Package Manager is an open source client designed for command-line usage. If you are interested in exploring private repositories offering private WinGet package hosting, see private repositories.

Documentation

Please check the overview for detailed topics. Common topics for the WinGet Community repository are available below:

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Follow the instructions provided by the bot. You will only need to do this once across all Microsoft repositories using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct.
See the Code of Conduct FAQ or
contact [email protected] with any additional questions or comments. More information is available in our Contributing document.

To avoid doubt, you may not make any Submissions linking to third-party materials if such Submission is prohibited by the applicable third party and/or otherwise violates such third party's rights.

Doc README (`doc/README.md`)

Documentation Overview

Authoring a Manifest

A few different tools are available to help you author a manifest.

Windows Package Manager Manifest Creator
YamlCreate.ps1
Other WinGet Manifest Creators developed by the community:
- Komac - Community Manifest Creator (maintained by @russellbanks)

If this is your first manifest submission, start with the first-time contributor checklist.

[!NOTE]
Only one package version (one multi-file manifest set) may be submitted per PR.
Non-manifest changes such as README.md, doc/, spelling updates, and tooling updates must be submitted in a separate PR.

Testing a Manifest

Now that you have authored your manifest, you should make sure it works as expected.

[!NOTE]
You will need to run winget settings --enable LocalManifestFiles in an administrative shell before working with local manifests.

Locally

Verify the syntax by executing the following command:

text

winget validate --manifest <path-to-manifest>

Test the install by executing the following command:

text

winget install --manifest <path-to-manifest>

For more details, see "Submit packages to Windows Package Manager" at Microsoft Docs.

In Windows Sandbox

You can use the Sandbox Test PowerShell script for testing a manifest installation in Windows Sandbox. The manifest will be also validated.

Just provide the path to manifest as parameter:

text

.\Tools\SandboxTest.ps1 <path-to-manifest>

Submitting a Manifest

To submit a package to this repository, you should follow these steps:

Follow the Contributing guidelines.
Author a Manifest.
Test your manifest.
If this is your first time submitting a manifest, review the first-time contributor checklist.
Submit your pull request (PR).
Respond to any feedback in your PR.

[!NOTE]
Please check the package's manifest you intend to submit does not already exist in the repository, and there are no open PRs for it in order to avoid duplicates.

Submit your PR

Once you have verified your manifest, it's time to submit a PR. Place your manifest in a folder path that matches the following structure:

text

manifests\<first lower case letter of publisher>\<publisher>\<package>\<version>\

Your PR must be limited to a single package version. If you also need to update documentation, spelling files, repository tooling, or other non-manifest content, open a separate PR for those changes.

Validation Process

Your PR will go through a validation process. The core team or the Microsoft bot (BOT) will use labels to assist during the process. In case of a failure, the BOT will suggest the problem with the submission and assign the PR back to you.

Community Repository Policies

The WinGet community repository has a set of policies restricting the use of certain manifest fields in PRs. These policies primarily affect optional metadata fields restricted to verified developers. Some fields are automatically populated during our validation process like the fields for icons.

[!NOTE]
The verified developer workflow is still in progress.

Respond to PR feedback

If your PR has been assigned to you, a timer will be triggered. If there is no activity for 5 days, a No-Recent-Activity label will be added. If there is still no activity after a further 3 days, the PR will be automatically closed.

Submissions to the repository are reviewed by Windows Package Manager administrators and/or community moderators. These individuals are identified in Moderation.

Doc Manifest README (`doc/manifest/README.md`)

WinGet Manifests

The Windows Package Manager supports several different schema versions. The intent is to follow semantic versioning so earlier versions of the WinGet client are able to install packages using earlier versions of the schema.

This repository contains manifests for packages submitted by publishers and independent community members. Ideally, software publishers will automate the submission process when new releases are made available.

As new releases of the WinGet client are developed with new features and functionality, the schema is routinely updated. Detailed documentation is made available to help authors understand the behaviors associated with keys and values in the YAML manifests.

The community repository will often delay support for new schema versions until enough devices have been updated so customers can benefit from the newly added manifest keys. Please use the recommended schema version mentioned in the PR template.

Manifest Schema Versions

Doc Private README (`doc/private/README.md`)

Third-party repositories

Microsoft is working with multiple partners to develop protocols or an API to enable third-party repositories.

Third-party repository implementations

The following projects let you host your own, private winget repository:

winget.Pro open source private winget repository with a hosted option
WinGetty open source private winget repository with a hosted option and multi-user support
Winget-Repo open source private winget repository with client management and other unique features
rewinged open source private winget repository creator

Third-party repositories

These public repositories offer additional packages that are not included in winget-pkgs:

winget-extras public winget repository by pl4nty. Specializes in packages that were rejected from winget-pkgs for various reasons
Cloudflight public winget repository by cloudflightio. Hosted by the developer of, and distributes, Cloudflight.DockerInWSL

Please feel welcome to submit a pull request to add your company's third-party repository offering to this list.

Doc Manifest Schema 1.0.0 README (`doc/manifest/schema/1.0.0/README.md`)

Windows Package Manager

Manifest Schema 1.0

The Windows Package Manager 1.1 client does not support all fields in the 1.0 schema.

Manifests submitted to the Windows Package Manager Community Repository should be submitted as a multi-file manifest. Only one version of a package may be submitted per pull request.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

Doc Manifest Schema 1.1.0 README (`doc/manifest/schema/1.1.0/README.md`)

Windows Package Manager

Manifest Schema 1.1

The Windows Package Manager 1.2 client does not support all fields in the 1.1 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

Manifests submitted to the Windows Package Manager Community Repository should be submitted as a multi-file manifest. Only one version of a package may be submitted per pull request. The singleton manifest format is supported by the client, but has been deprecated in the community repository. Rich tooling exists to generate manifests. The Windows Package Manager Manifest Creator and YAML Create were both designed to produce well formed and rich manifests.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

The publisher and application folders MUST match the values used to define the Id. See PackageIdentifier: in the YAML for more detail.
The version in the folder name MUST match the version field value in the YAML file. See PackageVersion: in the YAML for more detail.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

All tools must support a silent install to be permitted in the Windows Package Manager Community Repository. If you have an executable that does not support a silent install, then we cannot provide that tool at this time.

Provide as many fields as possible. The more meta-data you provide the better the user experience will be. In some cases, the fields may not yet be supported by the Windows Package Manager client (winget.exe).

The length of strings in this specification should be limited to 100 characters before a line break.

Doc Manifest Schema 1.10.0 README (`doc/manifest/schema/1.10.0/README.md`)

Windows Package Manager

Manifest Schema 1.10

The Windows Package Manager 1.10 client does not support all fields in the 1.10 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Summary of Changes from 1.9.0

[Version](version.md)

No Changes

[Default Locale](defaultLocale.md)

No Changes

[Installer](installer.md)

Added Authentication and Installer > RepairBehavior

[Locale](locale.md)

No Changes

Doc Manifest Schema 1.12.0 README (`doc/manifest/schema/1.12.0/README.md`)

Windows Package Manager

Manifest Schema 1.12

The Windows Package Manager 1.12 client does not support all fields in the 1.12 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Summary of Changes from 1.10.0

[Version](version.md)

No Changes

[Default Locale](defaultLocale.md)

No Changes

[Installer](installer.md)

Added font to InstallerType
Added font to NestedInstallerType

[Locale](locale.md)

No Changes

Doc Manifest Schema 1.2.0 README (`doc/manifest/schema/1.2.0/README.md`)

Windows Package Manager

Manifest Schema 1.2

The Windows Package Manager 1.3 client does not support all fields in the 1.2 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Doc Manifest Schema 1.28.0 README (`doc/manifest/schema/1.28.0/README.md`)

Windows Package Manager

Manifest Schema 1.28

The Windows Package Manager 1.28 client does not support all fields in the 1.28 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Summary of Changes from 1.12.0

[Version](version.md)

No Changes

[Default Locale](defaultLocale.md)

Added Icons
- NOTE: Icons is not an authorable field in the community repository. Icon metadata is populated by the validation pipelines during validation and cannot be added in pull requests.

[Installer](installer.md)

Added DesiredStateConfiguration

[Locale](locale.md)

Added Icons
- NOTE: Icons is not an authorable field in the community repository. Icon metadata is populated by the validation pipelines during validation and cannot be added in pull requests.

Doc Manifest Schema 1.4.0 README (`doc/manifest/schema/1.4.0/README.md`)

Windows Package Manager

Manifest Schema 1.4

The Windows Package Manager 1.4 client does not support all fields in the 1.4 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Doc Manifest Schema 1.5.0 README (`doc/manifest/schema/1.5.0/README.md`)

Windows Package Manager

Manifest Schema 1.5

The Windows Package Manager 1.5 client does not support all fields in the 1.5 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Doc Manifest Schema 1.6.0 README (`doc/manifest/schema/1.6.0/README.md`)

Windows Package Manager

Manifest Schema 1.6

The Windows Package Manager 1.6 client does not support all fields in the 1.6 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Doc Manifest Schema 1.7.0 README (`doc/manifest/schema/1.7.0/README.md`)

Windows Package Manager

Manifest Schema 1.7

The Windows Package Manager 1.7 client does not support all fields in the 1.7 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Summary of Changes from 1.6.0

[Version](version.md)

No Changes

[Default Locale](defaultLocale.md)

No Changes

[Installer](installer.md)

Added InstallerSwitches > Repair
Added RepairBehavior and Installer > RepairBehavior

[Locale](locale.md)

No Changes

Doc Manifest Schema 1.9.0 README (`doc/manifest/schema/1.9.0/README.md`)

Windows Package Manager

Manifest Schema 1.9

The Windows Package Manager 1.9 client does not support all fields in the 1.9 schema.

The Windows Package Manager uses manifests (YAML files) to locate and install packages for Windows users. This specification provides references to JSON schemas as well as best practices.

A multi-file manifest contains:

One version (JSON Schema) file
One default locale (JSON Schema) file
One installer (JSON Schema) file
Additional optional locale (JSON Schema) files

YAML file name and folder structure

YAML files shall be added to the repository with the following folder structure:
manifests / p / publisher / package / packageVersion / publisher.package.<manifestFile>.yaml

Example:
manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

Manifests are partitioned by the first letter of the publisher name (in lower case). For example: m.
Publisher folder is the name of the company that publishes the tool. For example: Microsoft.
The child folder package is the name of the application or tool. For example: WindowsTerminal.
The child folder package version is the version of the package. For example: 1.6.10571.0.
The filename must be a combination of the publisher name and the application name. For example: Microsoft.WindowsTerminal.yaml.

There are two primary types of manifests. A single file manifest (singleton) and a multi-file manifest.
JSON schemas have been provided
to help strongly type attributes and requirements.

YAML Syntax

Each field in the file must be PascalCased and cannot be duplicated.

Best Practices

The package identifier must be unique. You cannot have multiple submissions with the same package identifier. Only one pull request per package version is allowed.

Avoid creating multiple publisher folders. For example, do not create "Contoso Ltd." if there is already a "Contoso" folder.

The length of strings in this specification should be limited to 100 characters before a line break.

Summary of Changes from 1.6.0

[Version](version.md)

No Changes

[Default Locale](defaultLocale.md)

No Changes

[Installer](installer.md)

Added InstallerSwitches > Repair
Added RepairBehavior and Installer > RepairBehavior

[Locale](locale.md)

No Changes

Doc Authoring (`doc/Authoring.md`)

Authoring Manifests

First, we want to say thank you. Your contribution is highly valued, and we appreciate the time you have taken to get here and read this document. Let's start with a few definitions to help you understand our vocabulary.

Definitions

What is a manifest?

Manifests are YAML files in this repository containing metadata used by the Windows Package Manager to install and upgrade software on Windows. These files are organized under the manifests directory. The directory structure is partitioned to make navigation easier on GitHub.

What is a package?

A package refers to an application or program. Each package is uniquely identified by a "PackageIdentifier," typically in the format Publisher.Package. Additional segments may appear, separated by periods, for specific cases.

What is a version?

Package versions correspond to specific releases. These may follow semantic versioning or other formats, such as date-based versions. The YAML key for a package version is "PackageVersion."

Understanding the directory structure

The directory structure for a manifest is determined by the "PackageIdentifier" and "PackageVersion." For example, the directory for Microsoft Windows Terminal version 1.6.10571.0 would be:

manifests / m / Microsoft / WindowsTerminal / 1.6.10571.0

The first directory is the lowercase first letter of the "PackageIdentifier."
Subsequent directories match each segment of the "PackageIdentifier" (case-sensitive).
The final directory matches the "PackageVersion"

First steps

If this is your first contribution to the community repository, use the first-time contributor checklist alongside this guide as you work through the authoring steps.

Before creating and submitting a manifest, check if the package already exists:

Run winget search in your terminal.
Search for the package in this repository using GitHub's search box.
Check for existing pull requests related to the package.

What next?

Review the Manifest Specification. If the process seems complex, you can create a new issue and select Package Request/Submission 👀.

Manifests submitted to this repository must be multi-file manifests. The minimum required files are:

A version file
A defaultLocale file
An installer file

When you are ready to submit your work, keep the PR limited to one package version (one multi-file manifest set). If you also need to update README.md, doc/, spelling files, or other non-manifest content, submit those changes in a separate PR.

Creating your first manifest

If the package doesn't already exist, start creating your package manifest. We recommend using the Windows Package Manager Manifest Creator (Winget-Create), a command-line tool that guides you through the process and validates your manifest.

Alternatively, you can use the YamlCreate.ps1 Script. See the script documentation for details.

Installer Architectures

When specifying installer types, ensure the architecture reflects the installed binaries, not just the installer itself. For example, an x86 installer that installs x64 binaries should have its architecture set to x64.

How do I install Winget-Create?

Download the latest release from the Winget-Create GitHub repository or install it using Winget:

powershell

winget install wingetcreate

Creating your manifest with Winget-Create

After installing Winget-Create, generate your first manifest by running:

powershell

wingetcreate new <Installer URL(s)>

Explore other commands for updating existing manifests or submitting new manifests.

Validation

If you manually edit the YAML, validate your manifest using the following command:

powershell

winget validate --manifest <Path to manifest>

When you submit a PR, a GitHub App automatically runs the Validation Pipeline on your manifest and installers, reporting results directly on the PR. For a detailed description of each step and how to resolve failures, see the Validation and Validation Failure Guide documents.

Testing

Test your manifest before submission to ensure it meets quality standards:

Verify the application installs unattended.
Verify the installer URL is stable, version-specific, and points to the intended release asset.
Ensure the application version matches the "PackageVersion" or includes AppsAndFeaturesEntries if necessary.
Confirm the application publisher matches the defaultLocale "Publisher" or includes AppsAndFeaturesEntries if necessary.
Check that the application name matches the defaultLocale "PackageName" or includes AppsAndFeaturesEntries if necessary.

Enable local manifest testing with:

powershell

winget settings --enable LocalManifestFiles
winget install --manifest <path>

For a more isolated test, use the SandboxTest.ps1 Script to test in Windows Sandbox.

Advanced Authoring

AppsAndFeaturesEntries

Most installers write accurate version data to the Windows Registry, but not all. To help with version matching and correlation between the installed application and the manifest in repo, additional AppsAndFeaturesEntries metadata can be used. These include the PackageFamilyName, ProductCode, UpgradeCode, and InstallerType. Additional information on how AppsAndFeaturesEntries affect version matching, package correlation, and sort order can be found below.

What is Version Matching & Package Correllation?

Version Matching and Package Correlation is the process by which WinGet attempts to correlate the metadata for an application installed on your machine and match it to a specific package (Package Correlation) and a specific version of that package (Version Matching) which is available in any source. The goal is to accurately determine the currently installed application and its version so that upgrades can be correctly suggested when available (and not suggested when not available). To do this, WinGet relies on data in Windows Registry and the information available from your configured sources.

When is AppsAndFeaturesEntries needed?

There are a few typical use cases when AppsAndFeaturesEntries should be specified in a manifest.

The installer does not write a DisplayVersion to registry and either of the following are true:
1. The DisplayName contains the version.
2. The ProductCode contains version.
In either of these cases, the respective field is required in every manifest to accurately match the installed package version to an available version from the source.
The PackageVersion differed from the installer's DisplayVersion at any point in the manifest history.

In this case, DisplayVersion is required in every manifest to prevent version range mapping errors. If the field is left out, users will be caught in an upgrade loop where the Available version shown when running winget upgrade is lower than the PackageVersion of the latest manifest.
The DisplayVersion the installer writes to the registry is inherently un-ordered or cannot be sorted properly by WinGet

There are many ways that publishers choose to version their software. This leads to some cases where the way WinGet sorts versions will not work properly. Some examples include packages that only use commit hashes for their releases, packages which prefix the version number with a string, or packages using date versioning of DD-MM-YYYY.

When this happens, PackageVersion should be set to something which is sortable by WinGet and DisplayVersion should be set to the value the installer writes to the registry. For more information, see the section on Version Sorting in WinGet
The InstallerType of the installer which writes the registry keys does not match the InstallerType of the manifest

In some cases an EXE installer may call an embedded MSI which writes data to the registry in a different format. While the InstallerType may be correctly identified in the manifest, the WinGet CLI will detect the registry entries as being from an MSI and return an error that the installation technology does not match when running winget upgrade. This requires the InstallerType to be specified in AppsAndFeaturesEntries

For more information on how to specify AppsAndFeaturesEntries and what the available metadata fields are, please see the Manifest Specification.

Version Sorting in WinGet

Inherently, all versions are strings. Whether a publisher uses a date code, a commit hash, or some other crazy format they are all saved as string values in the Windows Registry. In fact, a semantic version is just a string with a certain format. To convert these strings into versions and sort them, WinGet goes through the following process.

[!IMPORTANT]
Step 1 of the below process only occurs in WinGet version 1.9.1763-preview or newer
If you are using an older version of WinGet, version preambles may not be handled correctly

If there is a digit before the first . or there is no ., trim off all leading non-digit characters.
Examples:
- v1.0.1 becomes 1.0.1
- version 12 becomes 12
Split the string at each ., discarding the .
Create a new Part from each of the split sections
- A Part consists of two components - an integer, and a string
- To create a Part, whitespace characters are first trimmed from the start and end of the section
- Then, numeric characters are parsed from the start of the section and used to create the integer.
- Once a non-numeric character is encountered, the remainder of the section is considered the string
- Example: If the section is 2024Mar15, then 2024 → integer and Mar15 → string
Compare the two parts created from the first section of the Version.
- If the two parts are not equal, whichever Part is larger corresponds to the larger version
- See below for an explanation on how parts are compared
If the two parts are equal, repeat step 3 with each consecutive pair of parts
- If both versions have no more parts, they are equal
- If one version has more parts and the other does not, pad the shorter version with an additional 0 as needed

When comparing one Part to another, WinGet goes through the following process.

Compare the two integer values
- If the two integer are not equal, whichever Part has the larger integer is larger
If the two integer are equal, check if there is a value in string
- If both values of string are empty, the parts are equal
- If one Part has a value in string and the other does not, the Part which does not have a value in string is considered to be greater
- Example: When comparing 34 and 34-beta, the integer is equal for both (34). However, the string for the former is empty and the string for the latter is -beta, so 34 is the larger Part. This leads to 1.2.34 being considered a higher Version than 1.2.34-beta
If both parts have a value in string, perform a case-insensitive comparison of the two
- If the values of string are not equal, the lexicographic comparison determines which Part is larger

Examples of Version Comparisons

Version A	Version B	Comparison Result	Explanation
1.2.0	1.2	Equal	`Version B` will be padded with zeros to match the same number of `Parts` as `Version A`
1.2	1.2-rc	`Version A`	The `-rc` causes `Version B` to have a `string` in the second `Part` where `Version A` does not
1.2.3	1.2.4-rc	`Version B`	The `integer` on the third `Part` is larger for `Version B`
v1.2	1.1	`Version A`	The leading `v` will be trimmed off of `Version A`, and `1.2` is a higher version than `1.1` due to integer comparison in the second `Part`
1.2.3a	1.2.3b	`Version B`	`b` is lexicographically greater than `a`

Doc FAQ (`doc/FAQ.md`)

Frequently Asked Questions

What is an ARP Entry?
What is the difference between a Marketing Version and Package Version?
How do I submit a package?
How do I get the AppsAndFeaturesEntries for an installer?
What should I do if a package is being published by a new publisher?
How long do packages take to be published?
What does this label on my PR mean?
Why does a package have the version "Unknown"?
My applications keep upgrading even when up to date!
How can I use PowerShell to parse the output from winget?
Why do WinGet and AppInstaller have different versions?
How do I know the packages in the Community Repository are safe?
How do portable applications get "Installed"?

What is an ARP Entry?

ARP stands for Add and Remove Programs. In Windows, installer files put information about the package they have installed into the Windows Registry. This information is used to tell Windows exactly what a program is and how to uninstall or modify it. Users can view these entries through the Add and Remove Programs option in Control Panel, or by running appwiz.cpl. Alternatively, the Apps & features menu in Windows Settings can be used to view the entries. Each entry in the table is an ARP Entry, and the Windows Package Manager uses these entries to help determine which applications are currently installed on your system.

What is the difference between a Marketing Version and Package Version?

Sometimes publishers use two different versions to refer to software. The version most commonly seen on the website or download page for a package is the Marketing Version. This is generally is used for the PackageVersion field of manifests, but there are exceptions. The Package Version, sometimes referred to as Build Version,Actual Version, or DisplayVersion is the version which is written to the ARP entry. This value is what the Windows Package Manager uses to determine which version of an application is currently installed on your system, and should be mapped to the AppsAndFeaturesEntries >> DisplayVersion in a manifest.

How do I submit a package?

Getting started is the hard part. There are several tools which we recommend for both creating and submitting packages.

First is the Windows Package Manager Manifest Creator (a.k.a Winget-Create). Winget-Create is a command line tool that will prompt you for relevant metadata related to your package. Once you are done, Winget-Create will validate your manifest to verify that it is correct and allow you to submit your newly-created manifest directly to the winget-pkgs repository by linking your GitHub account.

Second is the YamlCreate PowerShell Script. This tool is great for those who are technically inclined and understand the basics of forking, cloning, and commits. YamlCreate iterates much faster than Winget-Create but has largely the same functionality. More information on YamlCreate can be found in the Script Documentation.

Need more information? Take a look at the document on Authoring Manifests and the Microsoft Documentation Site.

How do I get the AppsAndFeaturesEntries for an installer?

The best way to get the AppsAndFeaturesEntries, or the ARP Entries, for an installer is to run the installer inside of the Windows Sandbox. Instructions on how to enable the sandbox can be found at the link above, or in the SandboxTest PowerShell Script Documentation. The SandboxTest PowerShell Script is a great way to get the AppsAndFeaturesEntries for a manifest you have already created. The SandboxTest Script will validate and test the manifest by downloading and installing the package in the Sandbox and comparing the ARP Entries before and after the installation. For the technically savvy, @jedieaston has created an Add-ARPEntries Script which uses Docker to populate the AppsAndFeaturesEntries for an existing manifest. Please note, however, that only the ARP Entry for the Primary Component should be added when a package installs multiple components.

What should I do if a package is being published by a new publisher?

The best practice for this is to create a situation where the package automatically switches to the new publisher using the ARP Entries for the package. To do this, two copies of the package must be added to the repository - one under the original package identifier and one under a new package identifier for the new publisher. This will cause anyone on a package published by the old publisher to be updated to the new version, at which point the ARP Entries will cause the Windows Package Manager to match the package to the new publisher and all future updates will be taken from the new package identifier.

For the package version added under the old publisher, the metadata should be updated to be accurate to the new publisher, with the exception of the Publisher field, which should remain as the old publisher. Additionally, the AppsAndFeaturesEntries should be added for each installer node, being sure to keep the Publisher entry as the old publisher. The ProductCode entries should not be specified under this version.

For the package version added under the new package identifier, the metadata should be complete and accurate. Additionally, the AppsAndFeaturesEntries should be added for each installer node. The ProductCode entries should be specified under this version.

Additional Notes:
While this is currently the best practice, this may change in the future with the implementation of microsoft/winget-cli#1899 and microsoft/winget-cli#1900. The origination of this best practice can be found here

How long do packages take to be published?

The time it takes for a package to be published depends on several factors:

Pull Request Approval: When you submit a package to the repository, your pull request undergoes automated validation checks. Labels will be applied to indicate the results of these checks.
Community Moderator Review: All pull requests must be reviewed and approved by one of our community moderators.
Publishing Pipeline: After approval and merging, the pull request passes through the publishing pipeline. Once successful, you will see a comment and label indicating the status.

Typically, changes are published within one hour after the pull request is merged. If you don't see the changes published, check the WinGetSvc-Publish Pipeline for errors. If there are issues, verify if any existing issues have been reported. If not, create a new issue.

What does this label on my PR mean?

During the automated validation process, labels are added to pull requests to help the bots that manage the repository and the status of open requests. All of these labels are described in more detail on the Microsoft Documentation Site

Why does a package have the version "Unknown"?

A package version is marked as "Unknown" when the Windows Package Manager detects the package as installed but the publisher has not provided the version information in the DisplayVersion registry key.

Behavior in Different Versions:

Windows Package Manager v1.2: Packages with an unknown version are always re-installed when running winget upgrade.
Windows Package Manager v1.3 and later: These packages are excluded from upgrades by default but can be included using the --include-unknown switch.

Recommendation:

Contact the application's publisher and request them to set the DisplayVersion registry key in their installer if you frequently use a package with an unknown version.

My applications keep upgrading even when up to date!

Applications may continually upgrade due to the following reasons:

Unknown Version: Packages with an unknown version may trigger upgrades. This issue was resolved in Windows Package Manager v1.3.
Side-by-Side Installations: Multiple versions of the same application (e.g., Visual C++ Redistributables, .NET Desktop Runtimes) can coexist. The Windows Package Manager may attempt to upgrade older versions, causing a loop if the upgrades also install side-by-side.

Future Work:

Efforts to resolve these issues are being tracked in:

microsoft/winget-cli#2345

How can I use PowerShell to parse the output from winget?

Native PowerShell support is now available through the Microsoft.WinGet.Client module on the PowerShell Gallery. It provides PowerShell cmdlets that return structured objects, making it straightforward to use WinGet in scripts and automation without parsing text output.

Install the module with:

powershell

Install-Module -Name Microsoft.WinGet.Client

Take a look at the discussions for community examples and Q&A around PowerShell support.

Why do WinGet and AppInstaller have different versions?

WinGet and AppInstaller are two distinct pieces of software, even though WinGet is included as part of the AppInstaller package. Their versioning differs because:

Separate Software: Changes to WinGet, such as a major version increment, may not necessarily impact AppInstaller or require a version change for it.
Independent Updates: Each application can evolve independently, with updates and features specific to their respective functionalities.

This separation ensures that updates to one do not unintentionally disrupt the other.

How do I know the packages in the Community Repository are safe?

While not all the details can be made public, the general approach is a defense in depth.

All new manifests are first scanned to be sure the manifest has the correct syntax. Assuming the author created the manifest correctly, each installer is then checked. Installers are downloaded to a secured environment and scanned with multiple utilities to check for any form of malware; after this the installer is executed and the installation is validated. This validation includes checking that no system files were changed, no suspicious services were added, and a multitude of other checks are performed to ensure the program is exactly what it appears to be. The application is also run after installation to be sure that no suspicious processes are kicked off.

The last automated check is a content validation to ensure that the package description and other metadata fields don’t violate one of the policies in place such as those against excessively profane language or adult content. There are additional manual checks in place, as each submission requires moderator approval before it can be merged. This gives an extra opportunity for moderators to check for the installation of any potentially unwanted applications, applications which change settings unexpectedly, and to ensure the installation truly works as expected.

How do portable applications get “Installed”?

WinGet performs several steps to "install" portable applications, mimicking the behavior of traditional installers:

Download and Move Files: The application files are downloaded and moved into an installation directory.
Registry Entries: Registry entries are created to make the application appear as an installed program.
PATH Environment Variable: The application is added to the PATH environment variable, enabling CLI applications to work seamlessly.

PATH Behavior:

Developer Mode Enabled or Administrative Context: A links directory is created and added to the PATH.
Otherwise: The full path to the installation folder is added to the PATH.

These steps ensure that portable applications integrate smoothly into the system.

Doc FirstContribution (`doc/FirstContribution.md`)

First-Time Contributor Checklist

Use this checklist before you open your first manifest PR to microsoft/winget-pkgs. It focuses on the repository rules that most often cause first-pass validation failures.

Pre-submit checklist

Confirm there is not already an open PR for the same package version.
Keep the PR to one package version only. In this repository, that means one multi-file manifest set for a single PackageIdentifier and PackageVersion.
Keep the PR to manifest files only. If you also need to update spelling files, README.md, doc/, tooling, or any other non-manifest file, submit those changes in a separate PR.
Use a supported installer type and make sure the installer can run unattended.
Use a multi-file manifest set. Singleton manifests are not allowed in the community repository.
Add schema headers to every manifest file, including the # yaml-language-server: $schema=... comment at the top of each file.
Use the latest manifest version supported by the repository. See doc/manifest/README.md for the current schema versions.
Use a stable, version-specific installer URL from an official source whenever possible.

Validate the manifest locally:

powershell

winget validate --manifest <path-to-manifest>

Test the install locally:

powershell

winget settings --enable LocalManifestFiles
winget install --manifest <path-to-manifest>

[!NOTE]
winget settings --enable LocalManifestFiles requires elevation (run as administrator). On enterprise-managed devices, Group Policy may also block this setting. If you cannot enable local manifests, use Windows Sandbox with Tools\SandboxTest.ps1 instead (step 11).

If possible, test in Windows Sandbox with Tools\SandboxTest.ps1.
If your PR is a routine manifest submission, you do not need a separate issue first. Open an issue when you are proposing a repo change, discussing a policy/spec question, or reporting a broader problem.
After you submit the PR, watch for validation labels and review ValidationFailureGuide.md if the bot reports a problem.

One PR change means one package version

The repository enforces one PR change strictly:

Allowed: one package version represented by its full multi-file manifest set
Not allowed: two versions of the same package in one PR
Not allowed: a manifest submission plus unrelated manifest changes
Not allowed: a manifest submission plus non-manifest files such as spelling updates, README.md, doc/ content, or tooling changes

If you discover a documentation, spelling, or tooling fix while preparing a manifest, finish the manifest PR first and submit the repo/documentation change as a separate PR.

First-time contributor decision tree

mermaid

flowchart TD
    A[Start a manifest<br/>contribution] --> B{Existing PR for this<br/>package version?}
    B -- Yes --> C[Do not open<br/>another PR]
    B -- No --> D{Exactly one package<br/>version in this PR?}
    D -- No --> E[Split the work into<br/>separate PRs]
    D -- Yes --> F{Any non-manifest files<br/>in this PR?}
    F -- Yes --> G[Move non-manifest changes<br/>to a separate PR]
    F -- No --> H{Stable and version-specific<br/>installer URL?}
    H -- No --> I[Use a stable official<br/>release URL]
    H -- Yes --> J{Installer can run<br/>unattended?}
    J -- No --> K[Fix installer type,<br/>switches, or dependencies]
    J -- Yes --> L[Run winget validate<br/>--manifest <path>]
    L --> M{Validation<br/>succeeded?}
    M -- No --> N[Fix manifest issues<br/>and validate again]
    M -- Yes --> O[Run winget install<br/>--manifest <path>]
    O --> P{Install test<br/>succeeded?}
    P -- No --> Q[Fix installer behavior,<br/>URL, or metadata]
    P -- Yes --> R[Submit the PR and<br/>monitor labels]

Doc Issues (`doc/Issues.md`)

Issues

GitHub uses Issues to track work. Community members are welcome to submit issues in this repository related to existing packages, new versions of packages, and existing manifests. In addition, requests for improvements to the validation pipelines and our bots are welcome.

Issues related to the WinGet client itself should be routed over to the winget-cli repository.

Request a Validation Feature

Please file issues using one of our Issue templates

Report an issue with a Manifest

Please file issues using one of our Issue templates

Request a New Package

Please file issues using one of our Issue templates

Request a New Package Version

Please file issues using one of our Issue templates

Doc Moderation (`doc/Moderation.md`)

Moderation Overview

The Windows Package Manager community repository is the location for manifests published in the default Windows Package Manager source. Automated pipelines validate and publish these manifests. The quality of the metadata has a direct impact on customer experience. Human review has proven to be an invaluable tool for ensuring we can provide the best experiences.

Moderators

In addition to Microsoft employees, several community members have been identified through their high-quality submissions, willingness to help others, and adherence to our code of conduct.

When we initially implemented moderation, we observed several objective criteria. These included the number of Pull Requests (PR)s made, the length of time they had been active in the project, and their interaction with others who submitted PRs.

Our intent was not to introduce a numbers game for others to achieve and automatically become a moderator. Our goal from now on is to ensure the community is sufficiently supported by individuals who have the technical knowledge and a proven track record of success. Becoming a moderator is like becoming a Microsoft Most Valuable Professional. There isn't a set formula. We're looking at what individual contributors are doing, and how they are doing it. If the need arises to add additional moderators, nominations may come from one of the core team members or an existing moderator. We will publicly disclose the nomination in a discussion. If the nominee agrees to the requirements in this document, they may be awarded the status of moderator.

Windows Package Manager Administrators
@AmelBawa-msft
@denelon
@dkbennett
@florelis
@hackean-msft
@JohnMcPMS
@Madhusudhan-MSFT
@msftrubengu
@ranm-msft
@stephengillie
@yao-msft

Community Moderators
@ImJoakim
@ItzLevvie
@jedieaston
@mdanish-kh
@russellbanks
@Trenly

Emeritus Moderators

We are grateful to the following community members for their service as moderators. Their contributions helped shape the Windows Package Manager community repository, and we thank them for their dedication and the time they gave to support contributors. Emeritus moderators are always welcome to return as active moderators on request.

Emeritus Moderators
@KaranKad
@OfficialEsco
@quhxl

Information for Contributors

Sometimes contributors may request assistance from moderators in order to take action on issues or pull requests. This section is designed to help contributors know how best to contact moderators.

Before You Request Assistance

Before requesting assistance, please work through these recommendations first:

Please be patient. Moderators may be busy or working on pressing matters. They generally prioritize the oldest open pull requests that have completed validation and are otherwise ready for moderator review. A pull request's exact position may vary because different submissions require different levels of scrutiny:
- New versions ready for moderator review, oldest first: Updates to established packages may require less scrutiny when prior manifests provide clear precedent for the package identity, installer source, and metadata.
- New packages ready for moderator review, oldest first: New packages generally require more scrutiny because moderators must establish package identity, installer provenance, metadata accuracy, and policy compliance without prior manifest history.
- Pull requests awaiting author feedback, oldest first: These pull requests are not currently waiting on moderator approval. Review the comments and validation labels, make the requested changes, and respond when the pull request is ready for another review.
These lists can help you understand the approximate position and state of your pull request, but they are not strict queues. Validation results, security or policy concerns, package complexity, and contributor responses may change the order in which pull requests are reviewed.
If you've submitted a pull request and it hasn't been approved, review any comments and labels to ensure no action or information is outstanding from you.
If you're helping on an existing package (new version, change, etc), consider contacting any regular package maintainer and ask for their assistance. They may be able to help vouch for your issue/pull request or help explain why it's stuck.

In spite of the above, if the issue or pull request is urgent (i.e. critical security vulnerability, breaking change, etc.), it's better to ask first so that help can be added immediately while you work through the above questions.

Where to Request Assistance

GitHub Mentions

For infrequent contributors, GitHub @mentions are likely the easiest way to get attention. As there are many moderators in the project, the best way to know who to tag is to check recently closed pull requests and see which moderator(s) have closed recent pull requests. This is a generally indicative of which moderator(s) are active and able to assist.

[!NOTE]
Community moderators can assist with standard manifest reviews, but pull requests with a red Policy-*, Validation-Domain, or Validation-Executable-Error label require review by a Windows Package Manager administrator. Mentioning a community moderator will not advance an administrator-only review. The current administrators are listed at the top of this document.

Please ensure when you mention a moderator to include a clear and concise note of what action you are requesting. Please only mention a maximum of two moderators at a time to prevent miscommunications.

Matrix Room

[!NOTE]
Use of Matrix requires user discretion as it is a federated communication system. Any privacy policies, software EULAs, user content agreements, etc the user agrees to are unrelated to the winget-pkgs repository and the winget project. Users joining the Microsoft_winget-pkgs room are required to abide by the code of conduct

For frequent contributors, there is a Matrix room where many moderators regularly participate. For quick requests (e.g. "Could someone please check out PR#####?") which are addressed to the entire room rather than specific moderators, this is a better option than GitHub Mentions.

Any significant technical discussions should be posted on GitHub comments so that conversations and troubleshooting can be available to the community, search engines, etc.

Gitter.im (Homeserver) Link

Matrix Room Alias (for all other homeservers): #Microsoft_winget-pkgs:gitter.im

Information For Moderators

Expectations

Moderators are expected to continue behaving in a manner consistent with what led to their nomination. In addition, they are given the ability to approve PRs for manifests. This should not be seen as the goal, however. The goal is to help ensure high-quality manifests and to help the community with package submission. They may request to discontinue this responsibility at any time and for any reason, and it will be honored.

Maintaining Moderator Status

Moderator status reflects ongoing, active participation in the project. A moderator is considered active if they have reviewed at least ten (10) pull requests covering at least ten (10) different packages within the trailing twelve (12) months.

The core team periodically reviews moderators who fall below this activity bar. Removal is not automatic; each case is considered individually so that context — such as a temporary break or contributions in other areas of the project — can be taken into account. When a moderator is removed for inactivity, it is not a reflection on the quality of their past contributions, which remain appreciated.

Activity in other Windows Package Manager repositories may also be taken into consideration during this review, including:

winget-cli — the WinGet client (CLI, PowerShell modules, and COM API)
winget-cli-restsource — reference implementation for a REST-based winget package source
winget-command-not-found — PowerShell 7 module that recommends packages for unrecognized commands
winget-create — the Windows Package Manager Manifest Creator (wingetcreate)
winget-dsc — WinGet DSC resources and sample configurations
winget-studio — WinGet Studio

A moderator who has been removed for inactivity and later wishes to resume may be reinstated on request, at the discretion of the core team, without going through the nomination process again.

Reviewing Pull Requests

Moderators should review PRs to ensure the metadata is accurate and that the Windows Package Manager will behave predictably with the given manifest. This includes checking the metadata and testing the installation of packages. Ideally, common issues will be documented and referred to for the sake of consistency. This might also include tips and tooling to help with the process. Some users are new to GitHub and may need a bit more support. We've all been new to Git at one point.

Providing Feedback

Moderators are often on the front line when new issues are identified. They should collaborate with each other, the community, and the product team. This will help ensure the Windows Package Manager continues to improve. Sometimes this could be by creating an Issue or a Discussion. Other times this may just be discussion in a PR. Moderators are ambassadors for the Windows Package Manager. Their tone sets the example others will follow.

Moderator Tools and Powers

Moderators are given several extra permissions in this repository. This details out some of the actions they can perform.

Approving Pull Requests

Trigger: Approve a pull request

Moderators are able to approve most pull requests for automatic merge. When a moderator approves a pull request, the Moderator-Approved label will automatically be added. If the automatic validation finds no issues with the pull request, it will be automatically merged.

Re-Running Pull Request Validation

Trigger: Comment @wingetbot run on a pull request

Occasionally the automatic validation runs into an issue which is transient, or may be solved by re-running the validation. This will remove most error labels and will cause the validation service to start a brand new validation instance.

Removing Pull Request Feedback

Trigger: Comment [Policy] reset feedback on a pull request

The bots which help keep the repository clean sometimes make mistakes or sometimes a moderator misclicks and accidentally requests changes. This can add the Needs-Author-Feedback or Needs-Attention labels to pull requests that don't need them. Moderators can remove these labels without re-running the pipelines to allow for the PR to be re-reviewed and merged.

Marking CLA as Signed

Trigger: Comment [Policy] CLA Signed on a pull request

When the Contributor License Agreement has been signed but the Needs-CLA label remains on a pull request, moderators can use this trigger to remove the label.

Removing Labels

Trigger: Comment [Policy] Reset Labels on a pull request or issue

Sometimes a label is misapplied or needs to be removed to keep things clean. This trigger will remove all labels that moderators have access to as well as some non-blocking pipeline labels such as Possible-Duplicate. After using this trigger, the applicable labels should be re-added using the triggers below.

Closing or Re-opening Pull Requests and Issues

Trigger: Comment Close with reason: <reason>; on a pull request or issue

Trigger: Comment Reopen with reason: <reason>; on a pull request or issue

In order to help keep the issues queues clean, moderators are able to close/re-open pull requests and issues. It is important to exercise discretion when closing/re-opening, ensuring that it is done with good reason.

[!IMPORTANT]
The ending semicolon is required.

Marking Issues as Duplicate

Trigger: Comment Duplicate of #<number>

When duplicate issues are raised, moderators are able to use this special variation of the close command to mark them as duplicate. This adds the Resolution-Duplicate label and provides additional information to the issue's author, as opposed to simply closing the issue.

Note: This does not work for cross-repository duplicates

Tagging of Issues and Pull Requests

Trigger: Comment [Policy] <label-name>

Moderators are often the first to see and triage new issues, and so they have the ability to apply certain labels to pull requests and issues. Below is a list of labels that moderators can apply:

Area-Bots
Area-Client
Area-External
Area-Matching
Area-Publish-Pipeline
Area-Rebuild-Pipeline
Area-Scope
Area-Validation-Pipeline
Blocking-Issue
Dependencies
DriverInstall
DSC
Error-Hash-Mismatch
Error-Installer-Availability
Hardware
Help-Wanted
Highest-Version-Removal
Icon
In-PR
Installer-Error
Installer-Issue
Interactive-Only-Download
Interactive-Only-Installer
Issue-Bug
Issue-Docs
Issue-Feature
Last-Version-Removal
License-Blocks-Install
Manifest-Singleton-Deprecated
Manifest-Validation-Error
Moderator-Approved
Needs-Attention
Needs-Author-Feedback
Needs-CLA
Needs-Manual-Merge
Needs-Manual-Review
Needs-Review
Network-Blocker
Package-Request
Package-Update
Portable-Archive
Portable-JAR
PSA
Scripted-Application
Testing
Upgrade-Issue
Validation-Skip-Automations
Version-Parameter-Mismatch
Windows-Features
Zip-Binary

[!NOTE]

Applying the following labels will automatically add Blocking-Issue

Hardware

Interactive-Only-Installer

License-Blocks-Install

Portable-Archive

Windows-Features

Zip-Binary

Adding Needs-Attention to a PR will automatically assign the repository maintainers

[Policy] Unblocked will remove Blocking-Issue label.

Doc Policies (`doc/Policies.md`)

Community Repository Policies

Policy documentation at Microsoft Learn covers most policies at a high level. Additional nuanced policies are detailed below.

Moderation

Manifests submitted to the community repository are subject to moderation.

Installer Types

WinGet supports the following installer types:

MSIX
APPX
MSI
Exe-based installers
Font files

These installer types may also be nested within the .zip (compressed) installer type.
Scripts are expressly disallowed as installers. Examples include:

Batch files (.bat)
PowerShell scripts (.ps1)

Installer Behaviors

Packages submitted to the community repository must install without requiring user interaction. The default installation mechanism in WinGet is "silent with progress", which means:

Installers may display a UI.
Users must not need to interact with the UI for a successful installation.

Security Scans and Potentially Unwanted Applications (PUA)

All packages submitted to the community repository are subject to multiple security scans as part of the validation pipeline. For more details on these checks, see How do I know the packages in the Community Repository are safe? in the FAQ, and the Validation documentation for a full description of all 10 validation steps.

Because of the security position this repository is placed in, there is a strict policy against Potentially Unwanted Applications (PUA) and potentially malicious software. If a package is flagged by any of the security scans in the validation pipeline, it cannot be accepted into the repository, regardless of the application's legitimacy or intent. This policy exists to protect users and maintain the integrity of the repository.

Policy updates related to PUA handling are being tracked in:

Manifest Agreements

WinGet manifests support adding agreements to manifests. These agreements are between the publisher and the user (or organization) installing the software. These applications are licensed to you by their owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.

When installer switches represent an explicit agreement, the manifest must include:

Agreement title
Agreement URL

The agreement body is not allowed. Only verified developers may provide agreement text.

Manifests with agreements require a review by Microsoft.

Manifest Types

WinGet supports a singleton manifest type, but it is prohibited in the community repository because:

It does not support localization well.
Existing tooling simplifies the process of generating manifests for WinGet packages.

Manifest URLs

The URLs in manifests should come from official sources/publishers for packages. In particular any URLs for installers need to be discoverable on the publishers website. In many cases the URLs for installers come from a CDN, and HTTP redirects are used to find the "final" url for installers. Some software is delivered via a "vanity" URL and publishers replace the binaries which will cause a hash mismatch until a new version of the manifest is published. The preference for WinGet manifests is to use unique URLs per version of a package to avoid the hash-mismatch errors.

Manifest Root Policy

This repository has two manifest root folders, manifests and fonts with InstallerType policy enforcement as follows:

manifests - InstallerType and NestedInstallerType font is not allowed.
fonts - InstallerType font and zip are the only permitted InstallerTypes, and font is the only permitted NestedInstallerType.

Doc Validation (`doc/Validation.md`)

Manifest Validation

When you submit a pull request to this repository, a GitHub App automatically runs a series of validation checks on your manifest and installers. The app reports its progress directly on the PR as GitHub Check Runs, providing real-time feedback without requiring you to navigate to an external build system.

Overview

The GitHub App runs 10 sequential validation steps, each building on the results of the previous one. If a step fails, subsequent steps that depend on it may be skipped. Results are surfaced directly on the PR's Checks tab and, when relevant, as comments on the PR itself.

If you need to re-trigger validation — for example, after fixing a hash mismatch or a transient network error — a moderator can comment @wingetbot run on your PR.

[!NOTE]
The validation GitHub App replaced the previous Azure DevOps (ADO) pipeline integration. The new app surfaces results directly on the PR and enables each validation step to run and report independently, reducing the need for a full re-validation after every change.

The 10 Validation Steps

01. Pull Request Validation

What it checks: The structural integrity of the PR itself — not the manifest content, but the way the PR is organized.

This step verifies:

The PR contains exactly one package version (one multi-file manifest set for a single PackageIdentifier and PackageVersion).
The PR contains only manifest files. Changes to documentation, tooling, spelling files, or any other non-manifest content must be submitted in a separate PR.
The PR does not introduce conflicts with the base branch.

Common failure causes:

Including more than one package or version in a single PR.
Mixing manifest changes with non-manifest file changes (e.g., README.md, doc/ files, spell-check dictionaries).
Merge conflicts with the base branch.

How to fix: See the first-time contributor checklist for guidance on PR structure. Resolve merge conflicts and separate non-manifest changes into their own PR.

[!NOTE]
The Contributor License Agreement (CLA) is checked by a separate automated process, not by this validation step. If the CLA has not been signed, a Needs-CLA label is applied and the PR cannot be merged until it is resolved.

Labels applied on failure: PullRequest-Error, Validation-Merge-Conflict

02. Manifest Validation

What it checks: Whether all manifest files conform to the manifest schema specification.

This step validates:

YAML syntax is well-formed (correct indentation, no tab characters, valid data types).
All required fields are present (PackageIdentifier, PackageVersion, PackageName, Publisher, License, InstallerType, InstallerUrl, InstallerSha256, and others depending on manifest type).
Field values match their expected types and formats (e.g., URLs are valid URIs, ManifestVersion uses a supported version).
The manifest uses a multi-file format — singleton manifests (ManifestType: singleton) are not permitted in the community repository.
The ManifestVersion is a supported schema version.
Each manifest file includes the correct # yaml-language-server: $schema=... header.
The directory path and file names exactly match the PackageIdentifier and PackageVersion declared in the manifest (case-sensitive).

Common failure causes:

Invalid YAML syntax (e.g., bad indentation, use of tabs, unquoted special characters).
Missing required fields.
Using a deprecated or unsupported ManifestVersion.
Using a singleton manifest type.
File or directory name casing mismatch with PackageIdentifier.

How to fix:

powershell

winget validate --manifest <path-to-manifest>

Address all reported errors. Refer to the manifest schema documentation for field definitions and requirements.

Labels applied on failure: Manifest-Validation-Error, Manifest-Version-Deprecated, Manifest-Path-Error

03. URLs Validation

What it checks: Whether the URLs declared in the manifest are valid, reachable, and use HTTPS.

This step verifies:

All installer URLs (InstallerUrl) and metadata URLs (PackageUrl, PublisherUrl, LicenseUrl, etc.) are syntactically valid.
Installer URLs respond with a successful HTTP status code (not 4xx or 5xx).
Installer URLs use HTTPS (not plain HTTP).
URLs do not point to sites flagged by Microsoft Defender SmartScreen as malicious or having low reputation.

[!NOTE]
This step checks URL reachability from the validation infrastructure's network. Some servers may block requests from Azure IP ranges.

Common failure causes:

The installer URL returns a 404 (file not found) or 403 (forbidden) response.
The URL uses http:// instead of https://.
The server blocks automated requests from the validation infrastructure's IP range.
The URL has a poor SmartScreen reputation.

How to fix: Verify the URL is correct, publicly accessible, and uses HTTPS. If the URL reputation is the issue, submit the URL for review.

Labels applied on failure: URL-Validation-Error, Validation-HTTP-Error, Error-Installer-Availability

04. URL Domain Validation

What it checks: Whether the domain of the InstallerUrl is an approved, official source for the publisher.

The Windows Package Manager policy for manifest URLs requires installers to come from official publisher sources — the domain must be discoverable by navigating from the publisher's official website. This step checks the installer URL's domain against the expected domain for the publisher and flags indirect sources, unofficial mirrors, download aggregators, and URL shorteners.

This step verifies:

The InstallerUrl domain matches the expected domain for the publisher.
The URL does not use a URL shortener or redirect service.
The URL is not a third-party mirror or download aggregator.
If a redirect is used, the final destination URL is from an approved domain.

[!TIP]
Including PackageUrl in your manifest and ensuring the InstallerUrl can be reached by navigating from that URL helps moderators and the validation system confirm the URL is from an official source.

Common failure causes:

Using a CDN, mirror, or download aggregator URL instead of the publisher's direct download link.
Using a URL shortener (e.g., bit.ly, tinyurl.com).
Using a redirect URL rather than the final resolved URL.

How to fix: Use the direct URL from the publisher's official release location. If the URL redirects, follow the redirect chain to find the final URL. A PowerShell snippet to resolve redirect chains is available in the ValidationFailureGuide.

Labels applied on failure: Validation-Domain, Validation-Unapproved-URL, Validation-Indirect-URL

05. Manifest Policy Validation

What it checks: Whether the manifest metadata complies with the Windows Package Manager community repository policies.

This step scans manifest fields — including PackageName, Publisher, Description, Tags, ReleaseNotes, and others — against a set of content policies defined by Microsoft. The checks align with the Windows Package Manager Policies published on Microsoft Learn.

Policy checks include:

Policy	Description
2.1 General Content Requirements	Content must be safe for a general audience.
2.2 Names, Logos, and Third-Party Content	Must not misuse trademarks or impersonate other software.
2.3 Risk of Harm	Must not describe or facilitate harmful activities.
2.4 Defamatory Content	Must not be defamatory, libelous, or threatening.
2.5 Offensive Content	Must not contain unnecessarily offensive language or imagery references.
2.6 Alcohol, Tobacco, Weapons, and Drugs	Must comply with applicable laws and age-restriction requirements.
2.7 Adult Content	Adult content is not permitted.
2.8 Illegal Activity	Must not facilitate illegal activities.
2.9 Excessive Profanity	Must not contain excessive profanity.
2.10 Country/Region-Specific Requirements	Must comply with regional legal requirements.
2.11 Age Ratings	Must accurately reflect the target audience age group.
2.12 User Generated Content	User-generated content must be moderated appropriately.

A policy violation does not automatically block the PR — it triggers additional manual review by the WinGet team. The PR will have a Policy-Test-2.x label applied indicating which policy requires review.

Labels applied on review: Policy-Test-2.1 through Policy-Test-2.12

06. Catalog Content Verification

What it checks: Whether merging the PR would result in a valid, buildable catalog.

Rather than checking the manifest in isolation, this step simulates the effect of merging the PR and verifies that the full Windows Package Manager catalog would still build successfully. It focuses on cross-package relationships and version range integrity.

This step checks for:

DisplayVersion range overlaps — the most common failure. If the DisplayVersion written to the registry by this installer overlaps with the version range covered by an existing manifest version, the catalog cannot correctly map installed versions to available updates. This typically occurs when AppsAndFeaturesEntries → DisplayVersion is incorrect. See When is AppsAndFeaturesEntries needed? for guidance.
Dependency existence — if the manifest declares Dependencies, this step verifies that every referenced package and version actually exists in the catalog.
Removal safety — if the PR is removing a package or version, this step verifies that no other packages in the catalog declare a dependency on it. Removing a package that other packages depend on would break those dependents.

Common failure causes:

Missing or incorrect DisplayVersion in AppsAndFeaturesEntries, causing the version range for this manifest to overlap with an adjacent version.
Declaring a dependency on a package or version that does not exist in the catalog.
Removing a package that is listed as a dependency by one or more other packages.

How to fix: If the failure is a DisplayVersion overlap, review the AppsAndFeaturesEntries guidance in Authoring.md and ensure DisplayVersion accurately reflects what the installer writes to the registry.

Labels applied on review: Manifest-AppsAndFeaturesVersion-Error

07. Installers Scan

What it checks: The installer binaries themselves, using static analysis and multiple antivirus engines.

This step downloads each installer declared in the manifest and performs:

SHA256 hash verification — the hash of the downloaded file is compared against the InstallerSha256 value in the manifest. A mismatch causes this step to fail immediately.
Static antivirus scanning — the installer binary is scanned with multiple antivirus engines for known malware signatures and heuristic detection.
Potentially Unwanted Application (PUA) detection — the installer is checked against Microsoft's PUA criteria. Per the repository security policy, a package that is flagged as PUA cannot be accepted, regardless of the application's legitimacy.

[!IMPORTANT]
If your installer is flagged by a security scan, you can submit the file to Microsoft Defender for Business analysis as a potential false positive. Include the PR URL in your submission. After the false positive is resolved, a moderator can re-trigger validation with @wingetbot run.

Common failure causes:

The InstallerSha256 does not match the downloaded file. This often happens with "vanity URLs" that always point to the latest version — the file may have been updated after you generated the hash.
The installer is detected as malware or PUA by one or more antivirus engines.
The installer URL has become unreachable since the manifest was authored.

How to fix:

powershell

# Recalculate the hash after downloading the installer
winget hash <path-to-installer>

Update the InstallerSha256 value in the manifest if the hash has changed. Use a version-specific URL where possible to avoid future hash mismatches.

Labels applied on failure: Binary-Validation-Error, Error-Hash-Mismatch, Error-Installer-Availability

08. Installation Validation

What it checks: Whether the installer works correctly in a clean, automated test environment.

This step downloads the installer and runs it in an isolated environment as a standard (non-elevated) user. The test verifies:

Silent installation — the installer completes without requiring user interaction. Dialogs, license prompts, option screens, or UAC prompts that block progress will cause this step to fail.
Correct installer type — WinGet applies silent switches automatically for known installer types (nullsoft, inno, burn, wix, msi, msix). If the wrong InstallerType is declared, the wrong switches may be used, causing the installation to fail or launch interactively.
Elevation requirements — if the installer requires administrator privileges to write to protected locations (e.g., Program Files, HKLM registry keys) or install a Windows service, the manifest must declare ElevationRequirement: elevationRequired. Without this, the installer will fail in the standard-user test environment.
Successful completion — the installer exits with a success code.
Executable discovery — after installation, the main application executable can be located.
Post-install security scan — Microsoft Defender scans the installed files for malware. A detection at this stage results in a Validation-Defender-Error.

[!TIP]
Test your manifest locally before submitting:
powershell
winget settings --enable LocalManifestFiles
winget install --manifest <path-to-manifest>
For a fully isolated test, use the SandboxTest.ps1 script in Windows Sandbox.

Common failure causes:

Wrong InstallerType — use nullsoft, inno, burn, or wix instead of generic exe when applicable, so WinGet can pass the correct silent switches.
Missing or incorrect InstallerSwitches for Silent or SilentWithProgress.
Installer requires elevation but ElevationRequirement is not set.
A required dependency (runtime, framework, VC++ runtime package) is not present in the test environment.
The installer is a portable executable that should use InstallerType: portable instead of exe.
The installer triggers a UAC prompt that cannot be accepted in the automated environment.

How to fix: Verify the InstallerType is specific and correct. Add ElevationRequirement: elevationRequired if the installer needs elevation. Test locally in a non-elevated terminal to reproduce the environment. Review the accompanying PR comment for specific failure details.

Labels applied on failure: Validation-Unattended-Failed, Validation-Installation-Error, Validation-Shell-Execute, Validation-Executable-Error, Validation-Uninstall-Error, Validation-Defender-Error, Validation-Hash-Verification-Failed, Validation-MSIX-Dependency, Validation-VCRuntime-Dependency

09. Installer Metadata Validation

What it checks: Consistency between the manifest metadata and the actual installer binary, plus icon and installation metadata validation required for publishing.

This step examines the installer binary directly and compares its intrinsic metadata with what is declared in the manifest:

MSIX-specific validation — for MSIX and APPX packages, verifies that PackageFamilyName, SignatureSha256, and MinimumOSVersion are correct and consistent with the package manifest embedded in the MSIX.
Icon validation — extracts and validates the application icon from the installer for use in the Windows Package Manager catalog. Icons are displayed in tools such as the WinGet UI and must meet size and format requirements.
InstallationMetadata validation — validates any InstallationMetadata fields declared in the manifest against what the installer actually produces, ensuring the published metadata accurately describes the installed application.

[!NOTE]
This step may be skipped if a previous step (particularly 08. Installation Validation) failed, because this step relies on successfully running the installer to inspect the resulting installed state.

10. Validation Completed

What it checks: This is not a validation step in itself — it is a summary check that reports the overall result of the entire validation pipeline.

When all preceding steps have completed (whether passing, failing, or being skipped due to upstream failures), this check aggregates the results:

If all applicable steps passed, this check reports success and the Validation-Completed label is applied to the PR. The PR is then eligible for moderator review and potential automatic merge upon approval.
If one or more steps failed, this check reports failure and summarizes which steps did not pass. The appropriate error labels are applied.

This check exists to provide a single, clear status signal at the top of the PR's Checks list.

Labels applied on success: Validation-Completed

After Validation: What Happens Next?

Once 10. Validation Completed reports success:

The Validation-Completed label is applied to the PR.
A community moderator reviews the PR. Moderators check manifest quality, verify the package installs as expected, and confirm the metadata is accurate.
When a moderator approves the PR, the Moderator-Approved label is automatically applied.
If validation passed and the PR is approved, it is automatically merged.
After merge, the package passes through the publishing pipeline. Once successfully published, you will see a comment and label on the PR. Changes typically appear in the WinGet source within one hour.

Understanding Failure Labels

Each validation step applies specific labels when it fails. For a complete reference of all error labels, their causes, and how to fix them, see the Validation Failure Guide.

Authoring Manifests — how to create and structure manifest files
Validation Failure Guide — detailed explanation of every error label
First Contribution Checklist — pre-submit checklist for new contributors
Repository Policies — content, installer, and URL policies
Moderation Overview — who reviews PRs and how the process works
Windows Package Manager Policies — Microsoft Learn policy reference

Doc ValidationFailureGuide (`doc/ValidationFailureGuide.md`)

WinGet Package Validation: Common Failure Labels and How to Fix Them

When you submit a pull request to microsoft/winget-pkgs, a GitHub App automatically runs the Validation Pipeline on your manifest and installers, reporting results directly on the PR's Checks tab. If something fails, labels are applied to your PR to indicate what went wrong. This document explains each label, what causes it, and how to resolve it.

[!TIP]
Many issues can be caught before submitting by running:
powershell
winget validate --manifest <path-to-manifest>
winget install --manifest <path-to-manifest>
For isolated testing, use the SandboxTest.ps1 script or Windows Sandbox.

Status Labels
Error Labels
Content Policy Labels
Internal Error Labels
Moderator-Applied Labels
Quick Reference Table

Status Labels

These labels track the progress of your PR through the validation pipeline.

Label	Meaning
Azure-Pipeline-Passed	Your manifest passed automated testing. There may be additional manual verification required.
Validation-Completed	All checks passed. Your PR may be merged automatically after moderator review.
Needs-Author-Feedback	Something needs your attention. If not addressed within 5 days, `No-Recent-Activity` will be added. If there is still no activity after a further 3 days, the PR will be automatically closed.
Needs-Attention	The PR has been escalated to the WinGet engineering team for investigation.
Blocking-Issue	The PR cannot be approved until the blocking issue (indicated by an accompanying error label) is resolved.
Needs-CLA	You have not signed the Contributor License Agreement. The PR cannot be merged until the CLA is signed. This is checked by a separate automated process, independent of the validation pipeline.

Error Labels

[!IMPORTANT]
Pull requests with a red Policy-*, Validation-Domain, or Validation-Executable-Error label require review by a Windows Package Manager administrator. Community moderator approval alone cannot resolve or waive these labels. Review any validation details and requested changes first; if the label remains after those issues are addressed, the pull request must wait for administrator review.

Manifest & Path Errors

`Manifest-Validation-Error`

What it means: Your manifest has a syntax error or does not conform to the manifest schema specification.

Common causes:

Invalid YAML syntax (bad indentation, missing colons, incorrect types)
Missing required fields (PackageIdentifier, PackageVersion, PackageName, Publisher, etc.)
Using a singleton manifest (deprecated in the community repo — use multi-file manifests)

How to fix:

powershell

winget validate <path-to-manifest>

Address all reported errors and resubmit.

`Manifest-Version-Deprecated`

What it means: Your manifest uses a schema version that is no longer accepted by the repository.

How to fix: Update your manifest to use a supported schema version. The recommended schema version is 1.12.0 (1.10.0 is also accepted). Update the ManifestVersion field in all manifest files and ensure the # yaml-language-server: $schema=... comment references the correct version.

`Manifest-Path-Error`

What it means: Your manifest files are not in the correct directory structure.

Required structure:

text

manifests/<first-letter>/<Publisher>/<PackageName>/<PackageVersion>/
├── <PackageIdentifier>.installer.yaml
├── <PackageIdentifier>.locale.<language>.yaml
└── <PackageIdentifier>.yaml

Common causes:

Incorrect casing — PackageIdentifier and directory names are case-sensitive
Filenames don't match the PackageIdentifier
Manifest placed outside the manifests/ directory

How to fix: Ensure the directory path and filenames exactly match your PackageIdentifier and PackageVersion.

`PullRequest-Error`

What it means: The PR itself has structural problems.

Common causes:

PR contains files outside the manifests/ folder
PR contains manifests for more than one package or more than one version
Modified files that are not part of the manifest submission

How to fix: Each PR must contain exactly one package version (one multi-file manifest set). If you need to update non-manifest files such as README.md, files under doc/, spelling files, or tooling, submit those changes in a separate PR. See the first-time contributor checklist before resubmitting.

`Manifest-Installer-Validation-Error`

What it means: There are inconsistencies or missing values in the manifest discovered during MSIX package evaluation or installer metadata validation.

Common causes:

InstallerType mismatch between what is declared and what is detected (e.g., declaring exe for an installer that is actually portable)
Missing or incorrect PackageFamilyName for MSIX packages
Incorrect MinimumOSVersion for MSIX packages
Inconsistencies in AppsAndFeaturesEntries

How to fix: Verify that installer metadata matches the actual installer. For MSIX, ensure PackageFamilyName and SignatureSha256 are correct. Use the SandboxTest.ps1 script to inspect the installed state.

Installer & Binary Errors

`Binary-Validation-Error`

What it means: The installer failed static analysis during the Installers Scan pipeline step. This test runs the installer through multiple antivirus engines.

Common causes:

Installer flagged as malware or Potentially Unwanted Application (PUA)
SHA256 hash mismatch between the manifest and the downloaded installer
Installer URL is inaccessible

How to fix:

Verify the InstallerSha256 hash:
powershell
```
winget hash <path-to-installer>
```
If flagged as malware/PUA, submit the installer to Microsoft Defender for analysis as a potential false positive.
Ensure the installer URL is publicly accessible.

[!CAUTION]
ESRP scan blocking detections result in the Binary-Validation-Error label. This label cannot be waived by a moderator or administrator. Future handling for PUA detections is being evaluated for PUA broadly, remote-access tools, and encrypted-file detections, but these proposals do not currently provide an exception. The detected issue must be resolved—for example, by correcting or replacing the installer, or by having an incorrect detection cleared—before the pull request can pass a new validation run.

`Error-Hash-Mismatch`

What it means: The InstallerSha256 in your manifest does not match the hash of the file downloaded from InstallerUrl.

Common causes:

The installer was updated at the URL without updating the hash in the manifest
"Vanity URL" that always points to the latest version — the file changed after you generated the hash
Copy/paste error in the hash value

How to fix:

powershell

winget hash <path-to-installer>

Update the InstallerSha256 value in your manifest and resubmit.

Best practice: Use version-specific URLs rather than vanity URLs to avoid hash mismatches.

`Validation-Hash-Verification-Failed`

What it means: Similar to Error-Hash-Mismatch, but detected during installation testing. The installer at the URL changed between initial validation and installation testing.

How to fix: Same as Error-Hash-Mismatch — update the hash and use a stable, version-specific URL.

`Error-Installer-Availability`

What it means: The validation service could not download the installer.

Common causes:

The InstallerUrl is incorrect or broken
The hosting server blocks Azure IP ranges
The server requires authentication or specific headers

How to fix: Verify the URL is correct and publicly accessible. If the URL works from your machine but not in validation, add a comment to your PR — a WinGet engineer will investigate.

URL & Domain Errors

`URL-Validation-Error`

What it means: A URL in the manifest failed validation. This can be triggered by Microsoft Defender SmartScreen reputation checks or HTTP error responses (403, 404).

Common causes:

Installer URL returns 404 (file not found) or 403 (forbidden)
URL has a poor SmartScreen reputation
URL points to a site flagged for malicious content

How to fix:

Check that all URLs in the manifest are valid and accessible.
If the issue is reputation-based, submit the URL for review.
Look at the PR check details to identify which specific URL failed.

`Validation-HTTP-Error`

What it means: The InstallerUrl does not use HTTPS.

How to fix: Update the InstallerUrl to use https:// instead of http://.

`Validation-Domain`

What it means: The domain of the InstallerUrl does not match the expected domain for this publisher. WinGet policy requires that installers come directly from the publisher's release location.

Common causes:

Using a third-party CDN, mirror, or download aggregator instead of the official publisher URL
Using a URL shortener or redirector

How to fix: Use the official download URL from the publisher's website. If the flagged domain is legitimate, add a comment with publisher-controlled evidence showing how the package or download page leads to the installer URL. A Windows Package Manager administrator must review that evidence and determine whether the domain can be approved or waived; community moderators cannot make that decision.

[!TIP]
Including PackageUrl in your manifest and ensuring the InstallerUrl can be found by navigating the publisher's website from that URL helps speed up moderator reviews.

`Validation-Unapproved-URL`

What it means: Similar to Validation-Domain — the InstallerUrl domain is not an approved source for this publisher.

How to fix: Use the direct URL from the publisher's official release location.

`Validation-Indirect-URL`

What it means: The installer URL uses a redirect rather than pointing directly to the publisher's server.

How to fix: Replace the redirected URL with the direct/final URL from the publisher's server.

PowerShell: Find the final URL after redirects

powershell

Function Get-UrlResponse {
    Param
    (
        [Parameter(Mandatory = $true, Position = 0)]
        [string] $URL
    )
    try {
        $HTTP_Request = [System.Net.WebRequest]::Create($URL)
        $HTTP_Request.UserAgent = 'Microsoft-Delivery-Optimization/10.1'
        $HTTP_Response = $HTTP_Request.GetResponse()
        $ResponseUri = $HTTP_Response.ResponseUri
        $AbsoluteUrl = $HTTP_Response.ResponseUri.AbsoluteUri
        $HTTP_Status = [int]$HTTP_Response.StatusCode
        $ResponseLength = $HTTP_Response.ContentLength
        $Headers = @{}; $HTTP_Response.Headers.ForEach({ $Headers[$_] = $Http_Response.Headers[$_] })
    } catch {
        $HTTP_Status = 404
    }
    If ($null -eq $HTTP_Response) { $HTTP_Status = 404 }
    Else { $HTTP_Response.Close() }
    return @{
        Url           = $URL
        ResponseUrl   = $AbsoluteUrl
        ResponseCode  = $HTTP_Status
        ContentLength = $ResponseLength
        Headers       = $Headers
        Response      = $ResponseUri
    }
}

Installation Testing Errors

`Validation-Unattended-Failed`

What it means: The installer did not complete silently — it either timed out or required user interaction.

Common causes:

Incorrect installer type (e.g., exe specified for a nullsoft, burn, or inno installer, or msi for wix) — WinGet handles silent switches automatically for known types, so a wrong type means the wrong switches are used
Missing or incorrect silent install switches (/S, /silent, /quiet, etc.)
The installer displays a dialog that blocks progress (license agreement, options screen)
The installer triggers a UAC prompt that cannot be accepted in the automated test environment — if the installer needs elevation, add ElevationRequirement: elevationRequired to the manifest so WinGet handles it
A dependency is missing on the test machine
The exe installer type was specified instead of portable for an application that runs without an installer

How to fix:

Check that your InstallerType is correct — use nullsoft, inno, burn, or wix instead of generic exe or msi when applicable.
Verify your InstallerSwitches include the correct Silent and SilentWithProgress values.

Test locally:

powershell

winget install --manifest <path-to-manifest>

Use Windows Sandbox to confirm the install completes without interaction.

`Validation-Executable-Error`

What it means: Post-install validation could not successfully locate or run an expected application executable, or the executable returned an unexpected result.

Common causes:

The application installs to a non-standard location.
A command-line application requires an argument such as --version to exit successfully.
The executable requires a dependency that is unavailable in the validation environment.
The application is a service or background process without a suitable executable.
Installation did not complete successfully.

How to fix: Review the validation details and confirm that the application installs and runs correctly. If a command-line executable requires a specific argument, include the executable name and argument in a PR comment so a Windows Package Manager administrator can add the installation metadata. Any remaining Validation-Executable-Error requires administrator review; community moderators cannot resolve or waive it.

`Validation-Uninstall-Error`

What it means: The application did not clean up completely during uninstall testing.

How to fix: Verify that your application uninstalls cleanly. Check the PR comments for specific details about what was left behind.

`Validation-Installation-Error`

What it means: A general error occurred during manual validation of the package.

Common causes:

The installer requires administrator privileges but the manifest does not specify ElevationRequirement: elevationRequired. The validation infrastructure runs installers as a standard (non-elevated) user by default. If the installer needs to write to protected locations (e.g., Program Files), modify system registry keys (HKLM), or install a Windows service, it will fail without the correct elevation requirement.
A dependency is missing on the test machine.
The installer encountered an unexpected error during setup.

How to fix:

If the validation logs indicate an access-denied or permissions error, add ElevationRequirement: elevationRequired to your installer manifest. See the ElevationRequirement documentation for guidance on choosing the correct value.
Check the accompanying PR comment for specific next steps.

`Validation-Shell-Execute`

What it means: The installer failed to launch or did not complete during dynamic validation. WinGet was unable to execute the installer successfully via ShellExecute.

Common causes:

The installer requires administrator privileges but the manifest does not specify ElevationRequirement: elevationRequired. The validation environment runs as a standard user — if the installer unconditionally needs elevation (e.g., it writes to Program Files, modifies HKLM registry keys, or installs a system service), it will fail without this field.
The installer binary is corrupted or not a valid executable.
The installer depends on a runtime or framework that is not present on the test machine.

How to fix:

If the installer needs elevation to complete, add ElevationRequirement: elevationRequired to your manifest. Do not use elevatesSelf unless the installer has its own built-in logic to conditionally request elevation. See the ElevationRequirement documentation for details.
Test locally with winget install --manifest from a non-elevated terminal to reproduce the issue.
Verify the installer binary is valid and not corrupted.

`Validation-Defender-Error`

What it means: During dynamic testing (post-install), Microsoft Defender flagged a problem with the installed application.

How to fix:

Install the application and run a full Microsoft Defender scan.
If you can reproduce the detection, fix the binary or submit it for false positive analysis.
If you cannot reproduce it, add a comment to the PR for investigation.

Dependency Errors

`Validation-MSIX-Dependency`

What it means: The MSIX package has a dependency that could not be resolved during testing.

How to fix: Update the package to include the missing framework components or declare the dependency in the manifest's Dependencies section.

`Validation-VCRuntime-Dependency`

What it means: The package depends on a Visual C++ Runtime that was not available during testing.

How to fix: Either bundle the VC++ runtime with the installer or add the appropriate dependency to the manifest.

Other Validation Errors

`Validation-Merge-Conflict`

What it means: Your PR has a merge conflict with the base branch and cannot be validated.

How to fix: Resolve the merge conflict in your branch and push the updated commits.

`Validation-Error`

What it means: A general validation failure occurred during manual approval. This is a catch-all label.

How to fix: Read the accompanying PR comment for details on what failed and the next steps.

`Error-Analysis-Timeout`

What it means: The binary validation test timed out before completing.

How to fix: This is typically investigated by WinGet engineers. No action is usually required from you — the PR will be assigned for investigation.

Content Policy Labels

These labels indicate that manifest metadata triggered a content policy review. False positives can occur when a word or phrase is interpreted without its surrounding context. Open the 10. Validation Completed check and review its artifacts to find the flagged word or phrase.

Red Policy-* labels require review by a Windows Package Manager administrator; community moderator approval alone cannot resolve or waive them. Review the referenced policy and correct the metadata if necessary. When possible, you may resolve a false positive by accurately rewording the metadata—for example, replacing "explicit approval instructions" with "direct approval instructions." Do not omit or alter relevant facts merely to avoid a policy match. If no accurate correction is appropriate, the pull request must wait for administrator review.

Label	Policy
Policy-Test-2.1	General Content Requirements
Policy-Test-2.2	Content Including Names, Logos, Original and Third Party
Policy-Test-2.3	Risk of Harm
Policy-Test-2.4	Defamatory, Libelous, Slanderous and Threatening
Policy-Test-2.5	Offensive Content
Policy-Test-2.6	Alcohol, Tobacco, Weapons and Drugs
Policy-Test-2.7	Adult Content
Policy-Test-2.8	Illegal Activity
Policy-Test-2.9	Excessive Profanity and Inappropriate Content
Policy-Test-2.10	Country/Region Specific Requirements
Policy-Test-2.11	Age Ratings
Policy-Test-2.12	User Generated Content

Internal Error Labels

These labels indicate a service-side issue. Your PR will be assigned to WinGet engineers automatically. No action is typically required from you.

Label	Description
Internal-Error	Generic or unknown failure during testing.
Internal-Error-Domain	Error during URL domain validation.
Internal-Error-Dynamic-Scan	Error during post-install binary validation.
Internal-Error-Keyword-Policy	Error during manifest content policy validation.
Internal-Error-Manifest	Error during manifest processing.
Internal-Error-NoArchitectures	Could not determine the installer architecture.
Internal-Error-NoSupportedArchitectures	The current test architecture is not supported.
Internal-Error-PR	Error during PR processing.
Internal-Error-Static-Scan	Error during static analysis of installers.
Internal-Error-URL	Error during URL reputation validation.

Moderator-Applied Labels

These labels are applied by moderators during manual review and indicate issues that need author attention.

Label	Meaning
Error-Hash-Mismatch	Installer hash doesn't match — same as the automated label.
Error-Installer-Availability	Installer URL cannot be reached.
Interactive-Only-Installer	The installer requires user interaction and cannot run silently. This is a blocking issue.
License-Blocks-Install	A license agreement blocks silent installation. This is a blocking issue.
Manifest-Content-Incomplete	Manifest metadata is missing or insufficient.
Manifest-Singleton-Deprecated	Singleton manifests are no longer accepted — convert to multi-file format.
Version-Parameter-Mismatch	The version in the manifest doesn't match what the installer writes to the registry.
Portable-Archive	The installer is a portable archive that may need special handling. This is a blocking issue.
Scripted-Application	The package uses scripts (`.bat`, `.ps1`) as installers, which are not allowed.
Hardware	The package requires specific hardware. This is a blocking issue.

Quick Reference Table

Label	Category	Author Action / Review	Summary
`Manifest-Validation-Error`	Manifest	✅ Yes	Fix YAML syntax / schema errors
`Manifest-Version-Deprecated`	Manifest	✅ Yes	Update to a supported schema version
`Manifest-Path-Error`	Manifest	✅ Yes	Fix directory structure / file naming
`PullRequest-Error`	PR	✅ Yes	One package, one version per PR
`Manifest-Installer-Validation-Error`	Manifest	✅ Yes	Fix installer metadata inconsistencies
`Binary-Validation-Error`	Installer	✅ Yes	Resolve ESRP detection or installer issue; this label cannot be waived
`Error-Hash-Mismatch`	Installer	✅ Yes	Update `InstallerSha256`
`Error-Installer-Availability`	Installer	✅ Yes	Fix installer URL
`URL-Validation-Error`	URL	✅ Yes	Fix broken or untrusted URLs
`Validation-HTTP-Error`	URL	✅ Yes	Switch to HTTPS
`Validation-Domain`	URL	🔒 Administrator review	Use publisher's official URL or provide publisher-controlled evidence
`Validation-Unapproved-URL`	URL	⚠️ Maybe	Use approved publisher URL
`Validation-Indirect-URL`	URL	✅ Yes	Remove URL redirection
`Validation-Unattended-Failed`	Install	✅ Yes	Fix silent install switches
`Validation-Executable-Error`	Install	🔒 Administrator review	Verify the executable runs successfully and provide any required argument
`Validation-Installation-Error`	Install	✅ Yes	Fix installation failure (check elevation)
`Validation-Shell-Execute`	Install	✅ Yes	Fix installer launch failure (check elevation)
`Validation-Defender-Error`	Install	⚠️ Maybe	Fix or submit for false positive review
`Validation-Merge-Conflict`	PR	✅ Yes	Resolve merge conflict
`Validation-MSIX-Dependency`	Dependency	✅ Yes	Add missing framework dependency
`Validation-VCRuntime-Dependency`	Dependency	✅ Yes	Add VC++ runtime dependency
`Needs-CLA`	PR	✅ Yes	Sign the Contributor License Agreement
`Internal-Error-*`	Internal	❌ No	WinGet team will investigate
`Policy-Test-*`	Content	🔒 Administrator review	Review the policy and correct the metadata if necessary

Getting Help

Re-run validation: A moderator can comment @wingetbot run on your PR to re-trigger the validation pipeline.
Request review: See the moderation guidance to understand the review queues and determine whether your pull request needs a community moderator or a Windows Package Manager administrator. Before mentioning anyone, confirm that validation has completed and that no author action is outstanding.
File an issue: If you believe the failure is incorrect, open an issue.
Matrix chat: Join the WinGet-pkgs Matrix room for quick questions.

For more information, see the Validation Pipeline documentation and the Windows Package Manager Policies on Microsoft Learn. Please also reference the official validation documentation.

Doc Tools Build MinWinVHD (`doc/tools/Build-MinWinVHD.md`)

Using Build-MinWinVHD.ps1

The Build-MinWinVHD.ps1 script creates a new Virtual Hard Disk (VHD) using a mounted Windows ISO for use with a virtual machine. This image will have as few dependencies and apps enabled as possible, to provide the best approximation of the images uses by the validation pipelines. Although this is not the same image, it should be close enough to use for testing manifests for those who are unable to use Windows Sandbox and SandboxTest.ps1.

Summary

This script creates a dynamically sized VHDX, initializes GPT partitions (EFI + OS), applies a Windows image from a mounted ISO, configures basic UEFI boot, services the offline image (removes features / provisioned apps), and optionally creates a Hyper-V VM using the VHDX.

Prerequisites

Run as Administrator: The script must be executed from an elevated PowerShell session.
PowerShell version: Requires PowerShell 5.1 or newer due to use of built-in cmdlets and DISM commands.
Windows ISO downloaded and mounted: Mount the Windows 11 ISO (right-click -> Mount, or use Mount-DiskImage) and note the assigned drive letter (e.g., D:). ISO images can be downloaded from the official Microsoft page: https://www.microsoft.com/software-download/windows11
DISM and bcdboot: The script uses the built-in dism and bcdboot utilities. Ensure these commands are present on your path.
Hyper-V (optional): If the Hyper-V module is available and you want a VM created automatically, ensure Hyper-V is enabled and that you can manually create a new VM.

[!IMPORTANT]
The script includes an "aggressive" list of features and provisioned app removals. Review the script before running if you need specific Windows features or provisioned packages preserved.

Parameters

Argument	Description	Required	Default
-IsoDrive	Drive letter where the Windows ISO is mounted (string). Example: D:.	true	—
-ImageIndex	Index of the Windows image within `install.wim` or `install.esd` (int). Use DISM to list available indexes (for example `dism /Get-WimInfo /WimFile:D:\sources\install.wim`).	true	—
-VhdPath	Full path to create the VHDX file (string). Example: `C:\MinWin11.vhdx`.	true	—
-VhdSizeGB	Size of the VHDX in GB (int).	false	25
-VmName	Name of the Hyper-V VM to create (string).	false	MinWin11

How to determine image index

Use DISM to list images in the WIM/ESD on the mounted ISO. Replace D: with your ISO drive letter:

powershell

# For WIM
dism /Get-WimInfo /WimFile:D:\sources\install.wim

# For ESD (DISM supports reading ESD similarly)
dism /Get-ImageInfo /ImageFile:D:\sources\install.esd

Look for the Index : value you want to apply (for example, 1 for the first edition).

Basic usage examples

Open an elevated PowerShell prompt and run (example values shown):

powershell

# From the Tools folder
cd <path-to-repo>\Tools

# Basic: create a 25GB dynamic VHDX from the image at D:, using index 1
.\Build-MinWin11.ps1 -IsoDrive D: -ImageIndex 1 -VhdPath C:\MinWin11.vhdx

# With custom size and VM name
.\Build-MinWin11.ps1 -IsoDrive D: -ImageIndex 2 -VhdPath C:\MinWin11.vhdx -VhdSizeGB 40 -VmName "MyMinWin11"

What the script does (high level)

Locates install.wim or install.esd on the mounted ISO at \sources.
Creates a dynamic VHDX at the path provided (-VhdPath) and mounts it.
Initializes the disk as GPT and creates a 100MB EFI partition and the remaining OS partition.
Formats the partitions (EFI = FAT32, OS = NTFS).
Applies the Windows image to the OS partition using dism /Apply-Image.
Creates UEFI boot files with bcdboot.
Mounts an offline copy of the image for servicing and removes a predefined list of optional features and provisioned appx packages (see script for the removal list).
Runs component-store cleanup (/StartComponentCleanup /ResetBase) to reduce size.
Dismounts VHD and optionally creates a Hyper-V VM named -VmName if the Hyper-V cmdlets are present.

Output

A VHDX file at the path specified by -VhdPath (e.g., C:\MinWin11.vhdx).
If Hyper-V is available and -VmName does not exist, a new Gen 2 VM is created and attached to the VHDX.

Warnings & tips

The script will throw an error if it cannot locate install.wim or install.esd in the ISO sources folder.
Review and edit the features/provisioned-app removal lists in the script before running in production environments — the defaults are aggressive and intended for minimal builds.
If you prefer to inspect the VHD before dismounting, modify the script or run the VHD mounting steps manually.
Ensure sufficient free space on the volume where -VhdPath is located.

Troubleshooting

If the ISO is not mounted as a drive letter, use Mount-DiskImage -ImagePath "C:\path\to\Win11.iso" and then run Get-Volume or check Explorer to find the assigned drive letter.
If dism /Apply-Image fails, verify the -ImageIndex value, and confirm whether the image file is install.wim or install.esd.
If Hyper-V VM creation fails, verify the Hyper-V Windows feature is enabled and that you are running elevated PowerShell.

Using with other VM Providers

The produced VHDX (C:\MinWin11.vhdx) can be used with other hypervisors, but many providers require a different disk format; convert the VHDX to the format your provider expects before attaching.
QEMU/KVM: convert to qcow2 with qemu-img convert -O qcow2.
VMware: convert to vmdk with qemu-img convert -O vmdk (or use VMware tools if available).
VirtualBox: use VBoxManage clonemedium disk --format VDI or convert with qemu-img to vdi/vmdk as needed.
Before converting, ensure the VHDX is dismounted and not in use. After conversion, attach the converted disk to a VM configured for UEFI/GPT (Gen2/EFI) and the appropriate disk controller.
Expect to install or enable guest additions/tools for the target hypervisor and verify drivers (network, storage) inside the guest; hardware differences may require small post-boot fixes.

Doc Tools PRWatcher (`doc/tools/PRWatcher.md`)

Using PRWatcher.ps1

PRWatcher includes Watch-PRTitles, to give information about pull requests (PRs) from watching their titles in your clipboard. To use, load the file contents into your PowerShell application through your desired means. (Copy/paste, Import-Module, include in Profile, et cetera.) Then run "Watch-PRTitles" and the script will monitor your clipboard, attempting to parse PackageIdentifiers and version numbers, and comparing these to WinGet's public manifest.

Utility Functions

Additionally included are utility functions:

Get-CleanClip to extract the PackageIdentifier.
Search-WinGetManifest to streamline non-interactive WinGet search.

These are library functions also used in other Manual Validation functions, as part of the philosophy of building a declarative layer to handle operations and build objects, and an imperative layer on top to orchestrate operations. These utility functions are in the declarative layer, while Watch-PRTitles is in the imperative layer.

WinGet repository on GitHub

This script is designed for use with the WinGet package repository on GitHub, specifically for PR approvers and working with package PRs in general.

Additional files

This script uses Auth.csv to provide hints to help a PR approver identify packages with restricted manifest submitters. These hints are not authoritative and are planned to be superseded by a more formal process in the future.

Features

Logging of valid PR titles, filtering on PR # at the end.
Default semantic versioning for more accurate versions. Fail-back to string-based versioning is planned to be working again soon.
"Automatic removal" clipboard insertion of output, to paste as PR comment confirming that the newer version is already available through WinGet.

Command Line Arguments

PRWatcher provides additional arguments for more specific functionality.

Watch-PRTitles [-noNew] [-authFile C:\path\to\Auth.csv] [-LogFile C:\path\to\Log.txt]

-noNew

This setting prevents logging the PR title if the package isn't already in the WinGet public manifest. This allows for streamlining acceptance of existing package upgrades, so an approver can skip new packages for more thorough examination later.

-authFile

Location of Auth.csv - defaults to current path location. This might become a built-in web location in future versions.

-LogFile

Location of logging file - defaults to "Log.txt" in current path location.

-Chromatic

Color schemes, for accessibility and variety:

Doc Tools SandboxTest (`doc/tools/SandboxTest.md`)

Using SandboxTest.ps1

The SandboxTest.ps1 script allows you to test manifests locally using the Windows Sandbox without installing the application directly on your system.

Prerequisites

Fork and Clone the Repository
- Fork this repository.
- Clone the forked repository to your computer.
Enable Windows Sandbox
Ensure Windows Sandbox is enabled. Run the following command in PowerShell:
powershell
```
Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online
```
Restart your computer after the command completes.

System Requirements

Windows 10 or 11 Pro, Enterprise, or Education (build 18305 or later);
Windows Sandbox is not supported on Windows Home edition
AMD64 architecture
Virtualization enabled in BIOS
At least 4 GB of RAM, 1 GB of free disk space, and two CPU cores

Usage

Open a PowerShell terminal and navigate to the Tools folder:

powershell

cd <drive>\<path-to-parent>\winget-pkgs\Tools

Run the script with the full path to the manifest as an argument. This validates the manifest, opens Windows Sandbox, and attempts to install the package.

powershell

.\SandboxTest.ps1 <path-to-manifest> [<options>]

Supported Options

Argument	Description
-Manifest	Path to the manifest to install in the Sandbox
-Script	Post-installation script to run in the Sandbox
-MapFolder	Folder to map in Sandbox (default: current directory)
-WinGetVersion	Specify the version of WinGet to use in Sandbox
-WinGetOptions	Additional options for the `winget install` command
-SkipManifestValidation	Skip `winget validate -m <manifest>` if already validated
-Prerelease	Use preview release versions of WinGet
-EnableExperimentalFeatures	Enable WinGet experimental features
-Clean	Force re-download of WinGet and dependencies

[!IMPORTANT]
The -GitHubToken option has been removed. Use the WINGET_PKGS_GITHUB_TOKEN environment variable instead.

Examples

Test a Manifest with the Latest Stable WinGet

powershell

.\SandboxTest.ps1 <path-to-manifest>

Test a Manifest with the Latest Preview WinGet

powershell

.\SandboxTest.ps1 <path-to-manifest> -Prerelease

Test a Manifest with a Specific WinGet Version

powershell

.\SandboxTest.ps1 <path-to-manifest> -WinGetVersion 1.10.340 -Prerelease -Script {Write-Host 'Script finished'}

Install a Package from the Repository in Sandbox

powershell

.\SandboxTest.ps1 -WinGetVersion 1.9 -Script {winget install <PackageIdentifier> --accept-source-agreements}

Integration with Other Scripts

YamlCreate Script: Uses SandboxTest.ps1 to test newly created manifests.
PRTest Script: Depends on SandboxTest.ps1 to validate manifests submitted in pull requests.

Doc Tools YamlCreate (`doc/tools/YamlCreate.md`)

Using YamlCreate.ps1

Using the YamlCreate script is easy. First, create a fork of this repository and then clone it to your computer. Once the repository has finished cloning, open file explorer and navigate to the folder that the repository was cloned into. Inside this folder, you should be able to navigate to the Tools folder, which contains the script. Right click on "YamlCreate" and select "Run with PowerShell". If it is your first time running the script, you may see a message that it is installing some additional packages - NuGet, and powershell-yaml (See it on GitHub). These are required for the script to run.

Once the script begins, it will walk you through a series of prompts to create manifests. Enter the requested information for each of the prompts and once all the prompts are completed, the manifest will be generated! If you have Windows Sandbox enabled and the GitHub CLI installed, you can even automatically test and submit your manifest instead of having to do it manually.

Optional Software

Windows Package Manager

Because the script is meant for creating manifests for the Windows Package Manager, we highly recommend you install it. This allows the script to automatically validate the manifests that are generated and also provides you the ability to easily install other optional software packages. Instructions for installing the package manager can be found over on the winget-cli repository.

Windows Sandbox

The Windows Sandbox is an optional feature within windows that allows you to run a virtual environment to test software. The SandboxTest.ps1 script integrates with the Windows Sandbox to allow manifests to be tested without needing to install the software onto your machine. The script can automatically run the same validation as long as the Windows Sandbox is enabled. To enable the sandbox, open PowerShell and run the command Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online. Once the command completes, restart your computer to finish the installation.

Git

The script can automatically create commits and branches within your fork of the repo. In order to do this, you need to have Git installed. The easiest way to do this is to use winget! Open up PowerShell and install Git using winget install Git. This will allow the script to push the new manifest to your fork of the repository and provide you with a link to submit your pull request.

GitHub CLI

If you have Git installed, you can also create the pull request for your manifest directly from the script. You will have to install the GitHub CLI and authorize it with your GitHub Account. Again, winget makes installing the CLI easy. Open up PowerShell and install the GitHub CLI using winget install GitHub.CLI. Once the CLI is installed, close, then re-open PowerShell. To log in and authorize the CLI, run the command gh auth login. Follow the prompts that appear to finish the authorization.

Command Line Arguments

When running YamlCreate through the command line, you can specify additional arguments such as the package identifier or the package version. You can also use the settings switch to open the settings file. More information on the available settings is below.

.\YamlCreate.ps1 [-PackageIdentifier ] [-PackageVersion <version>] [-Mode <1-5>] [-Settings] [-SkipPRCheck]

YamlCreate Settings

YamlCreate offers a few settings to customize your manifest creation experience. The settings file is found in the %LOCALAPPDATA%\YamlCreate folder on Windows and /home//.config/YamlCreate on Linux and macOS. It is empty by default, but you can copy the sample below which describes what all of the available options are; or, you can enter just specific keys as you see fit.

text

/* Detailed source-code truncated for AI context efficiency. */

Doc Manifest Schema 1.0.0 DefaultLocale (`doc/manifest/schema/1.0.0/defaultLocale.md`)

Windows Package Manager

Manifest Schema v1.0.0 Default Locale File

All Windows Package Manager manifests in the Microsoft community repository are submitted using YAML syntax. A JSON schema is provided to aid authoring these files in editors, and in the other tooling related to the Windows Package Manager. This document provides detailed information regarding the usage of the YAML keys in the default locale file for multi-file manifests. Please review the Manifest Specification if you are not familiar with this file.

Fields

PackageIdentifier

The package unique identifier

Required Field

This key is the unique identifier for a given package. This value is generally in the form of Publisher.Package. It is case sensitive, and this value must match the folder structure under the partition directory in GitHub.

PackageVersion

The package version

Required Field

This key represents the version of the package. It is related to the specific release this manifests targets. In some cases you will see a perfectly formed semantic version number, and in other cases you might see something different. These may be date driven, or they might have other characters with some package specific meaning for example.

The Windows Package Manager client uses this version to determine whether or not an upgrade for a package is available. In some cases, packages may be released with a marketing driven version, and that causes trouble with the winget upgrade command.

The current best practice is to use the value reported in Add / Remove Programs when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior.

PackageLocale

The package meta-data locale

Required Field

This key represents the locale for package meta-data. The format is BCP-47. This value identifies the language for meta-data to be displayed to a user when no locale file matching their preferences is available. The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules for this file.

References:

Available languages for Windows
[Default Input Profiles (Input Locales) in Windows]

Note: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher

The publisher name

Required Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

Note: With the 1.0 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package when it has been installed. The impact is associated with winget upgrade and winget list.

PublisherUrl

The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl

The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl

The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package it is preferred over a generic privacy page for the publisher.

Author

The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package.

PackageName

The package name

Required Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

Note: With the 1.0 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. The impact is associated with winget upgrade and winget list.

PackageUrl

The package home page

Optional Field

This key represents the web site for the package.

License

The package license

Required Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license.

LicenseUrl

The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright

The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl

The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription

The short package description

Required Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

Note: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description

The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

Note: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker

The most common package term

Optional Field

This key represents the most common term users would search for when installing or upgrading a package. If only one package uses this moniker, then the install, list and upgrade command may match with this package.

Note:Moniker is the third property evaluated when searching for a matching package.

Optional Field

This key represents other common term users would search for when looking for packages.

Note: The best practice is to present these terms in all lower case with hyphens rather than spaces.

ManifestType

The manifest type

Required Field

This key must have the value "defaultLocale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion

The manifest syntax version

Required Field

This key must have the value "1.0.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.0.0 Installer (`doc/manifest/schema/1.0.0/installer.md`)

Windows Package Manager

Manifest Schema v1.0.0 Installer File

All Windows Package Manager manifests in the Microsoft community repository are submitted using YAML syntax. A JSON schema is provided to aid authoring these files in editors, and in the other tooling related to the Windows Package Manager. This document provides detailed information regarding the usage of the YAML keys in the installer file for multi-file manifests. Please review the Manifest Specification if you are not familiar with this file.

Fields

PackageIdentifier

The package unique identifier

Required Field

PackageVersion

The package version

Required Field

The Windows Package Manager client uses this version to determine if an upgrade for a package is available. In some cases, packages may be released with a marketing driven version, and that causes trouble with the winget upgrade command.

Note: The current best practice is to use the value reported in Add / Remove Programs when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior. This practice may seem contrary to using semantic versioning, but it provides the best end to end experience for customers. It will take time for publishers and ISVs to migrate to semantic versioning, and some may intentionally choose to preserve other versioning schemes.

Channel

The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

Note: This key is included for future use. The Windows Package Manager currently does not have any behavior associated with this key. The intent behind this key is to help disambiguate the different channels for packages lacking support for side by side installation. Some packages support having more than one package channel available on a system simultaneously; in this case it is better to use unique packages rather than channels. This key is intended to ensure the proper channel for a package is used during install and upgrade scenarios.

Platform

The installer supported operating system

Optional Field

This key represents the Windows platform targeted by the installer. The Windows Package Manager currently supports "Windows.Desktop" and "Windows.Universal". The Windows Package Manager client currently has no behavior associated with this property. It was added for future looking scenarios.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

MinimumOSVersion

The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerType

Enumeration of supported installer types. InstallerType is required in either root level or individual Installer level

Required Field

Note: The Windows Package Manager defaults to the install mode providing install progress. A best practice is to determine if one of the supported installer technologies was used to build an installer with the .exe file extension. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension.

Note: The Windows Package Manager does not support loose executables with the .exe or .com file extension directly. Compressed files containing installers, loose executables, and Progressive Web Applications (PWAs) are also not supported.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Scope

Scope indicates if the installer is per user or per machine

Optional Field

This key represents the scope the package is installed under. The two configurations are "user" and "machine". Some installers support only one of these scopes while others support both via arguments passed to the installer using "InstallerSwitches".

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallModes

List of supported installer modes

Optional Field

This key represents the install modes supported by the installer. The Microsoft community package repository requires a package support "silent" and "silent with progress". The Windows Package Manager also supports "interactive" installers. The Windows Package Manager client does not have any behavior associated with this key.

Note: Some installers will attempt to install missing dependencies. If these dependencies require user interaction, the package will not be allowed into the Microsoft community package repository.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerSwitches

Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

Note: The Microsoft community repository currently requires support for silent and silent with progress installation. Many custom .exe installers will require the proper switches to meet this requirement. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension. In the event the tool is unable to determine the tool used to build the installer, the publisher may have documentation for the proper switches.

Silent

Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

Note: When the Windows Package Manager installs a package using the "silent" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

SilentWithProgress

SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

This key represents switches passed to the installer to provide a silent with progress install experience. This is intended to allow a progress indication to the user, and the indication may come from an installer UI dialogue, but it must not require user interaction to complete. The Windows Package Manager currently defaults to this install experience.

Note: When the Windows Package Manager installs a package using the "silent with progress" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Interactive

Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

This key represents switches passed to the installer to provide an interactive install experience. This is intended to allow a user to interact with the installer. These would be used when the command winget install --interactive is executed.

Note: When the Windows Package Manager installs a package using the "interactive" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

InstallLocation

InstallLocation is the value passed to the installer for custom install location.

Optional Field

This key represents the path to install the package if the installer supports installing the package in a user configurable location. The <INSTALLPATH> token can be included in the switch value so the Windows Package Manager will replace the token with user provided path.

Log

Log is the value passed to the installer for custom log file path.

Optional Field

This key represents the path logs will be directed to if the installer supports specifying the log path in a user configurable location. The <LOGPATH> token can be included in the switch value so the Windows Package Manager will replace the token with user provided path.

Upgrade

Upgrade is the value that should be passed to the installer when user chooses an upgrade

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom

Custom switches will be passed directly to the installer by winget

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

InstallerSuccessCodes

List of additional non-zero installer success exit codes other than known default values by winget

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

Note: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

UpgradeBehavior

The upgrade method

Optional Field

This key represents what the Windows Package Manager should do regarding the currently installed package during a package upgrade. If the package should be uninstalled first, the "uninstallPrevious" value should be specified.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Commands

List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

Note: The Windows Package Manager does not update the path during the install workflow. In those cases, the user may need to restart their shell or terminal before the command will execute the newly installed package. The Windows Package Manager does not support any behavior related to commands or aliases.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Protocols

List of protocols the package provides a handler for

Optional Field

This key represents any protocols supported by the package. The Windows Package Manager does not support any behavior related to protocols handled by a package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

FileExtensions

List of file extensions the package could support

Optional Field

This key represents any file extensions supported by the package. The Windows Package Manager does not support any behavior related to the file extensions supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Dependencies

List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

WindowsFeatures

List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

WindowsLibraries

List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageDependencies

List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

ExternalDependencies

List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageFamilyName

PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

This key represents the package family name specified in an MSIX installer. This value is used to assist with matching packages from a source to the program installed in Windows via Add / Remove Programs for list, and upgrade behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

ProductCode

ProductCode could be used for correlation of packages across sources

Optional Field

This key represents the product code specified in an MSI installer. This value is used to assist with matching packages from a source to the program installed in Windows via Add / Remove Programs for list, and upgrade behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Capabilities

List of appx or msix installer capabilities

Optional Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

RestrictedCapabilities

List of appx or msix installer restricted capabilities

Optional Field

This key represents the restricted capabilities provided by an MSIX package.More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Installer

Package installer

Required Field

The key represents an installer for a package.

Note: Many of the keys related to installers may either be at the root level of the manifest, or included in an installer. Any values provided at the root level and not specified in an installer will be inherited.

InstallerLocale

Locale for package installer

Optional Field

This key represents the locale for an installer not the package meta-data. Some installers are compiled with locale or language specific properties. If this key is present, it is used to represent the package locale for an installer.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Architecture

The installer target architecture

Required Field

This key represents the hardware architecture targeted by the installer. The Windows Package Manager will attempt to determine the best architecture to use. If emulation is available and the native hardware architecture does not have a supported installer, the emulated architecture may be used.

InstallerUrl

The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256

Sha256 is required. Sha256 of the installer

Required Field

This key represents the SHA 256 hash for the installer. It is used to confirm the installer has not been modified. The Windows Package Manager will compare the hash in the manifest with the calculated hash of the installer after it has been downloaded.

Note: The Windows Package Manager Manifest Creator can be used to determine the SHA 256 of the installer. The winget hash <pathToInstaller> command can also be used to determine the SHA 256 of the installer.

SignatureSha256

SignatureSha256 is recommended for appx or msix. It is the sha256 of signature file inside appx or msix. Could be used during streaming install if applicable

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

Note: MSIX installers must be signed to be included in the Microsoft community package repository. If the installer is an MSIX this signature should be included in the manifest. The Windows Package Manager Manifest Creator can be used to determine the signature SHA 256. The winget hash --msix command can also be used to determine the signature SHA 256.

Installers

Array of package installers

Required Field

This key must be present for each installer for this version of the package. There may be multiple installer nodes to support different architectures, locales, install scopes (User vs. Machine)

ManifestType

The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion

The manifest syntax version

Required Field

This key must have the value "1.0.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.0.0 Locale (`doc/manifest/schema/1.0.0/locale.md`)

Windows Package Manager

Manifest Schema v1.0.0 Locale File

Locale Manifest

yaml

PackageIdentifier:            # The package unique identifier
PackageVersion:               # The package version
PackageLocale:                # The package meta-data locale
Publisher:                    # Optional publisher name
PublisherUrl:                 # Optional publisher home page
PublisherSupportUrl:          # Optional publisher support page
PrivacyUrl:                   # Optional publisher privacy page
Author:                       # Optional author
PackageName:                  # Optional package name
PackageUrl:                   # Optional package home page
License:                      # Optional package license
LicenseUrl:                   # Optional package license page
Copyright:                    # Optional package copyright
CopyrightUrl:                 # Optional package copyright page
ShortDescription:             # Optional short package description
Description:                  # Optional full package description
Tags:                         # Optional list of package terms
Agreement:                    # Optional package agreements
  - AgreementLabel:           # Optional agreement label
    Agreement:                # Optional agreement text
    AgreementUrl:             # Optional agreement URL
ReleaseNotes:                 # Optional release notes
ReleaseNotesUrl:              # Optional release notes URL
ManifestType: locale          # The manifest type
ManifestVersion: 1.0.0        # The manifest syntax version

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

PackageLocale - The package meta-data locale

Required Field

References

Available languages for Windows
[Default Input Profiles (Input Locales) in Windows]

Note: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Optional Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

Note: With the 1.0 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package when it has been installed. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package.

PackageName - The package name

Optional Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

Note: With the 1.0 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Optional Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package, it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Optional Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

Note: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

Note: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages.

Note: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreement - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Note: In the Windows Package Manager Community Repository, these are only allowed to be submitted by verified developers.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Optional Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

ManifestType - The manifest type

Required Field

This key must have the value "locale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.0.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.0.0 Version (`doc/manifest/schema/1.0.0/version.md`)

Windows Package Manager

Manifest Schema v1.0.0 Version File

All Windows Package Manager manifests in the Microsoft community repository are submitted using YAML syntax. A JSON schema is provided to aid authoring these files in editors, and in the other tooling related to the Windows Package Manager. This document provides detailed information regarding the usage of the YAML keys in the version file for multi-file manifests. Please review the Manifest Specification if you are not familiar with this file.

Fields

PackageIdentifier

The package unique identifier

Required Field

PackageVersion

The package version

Required Field

DefaultLocale

The default package meta-data locale

Required Field

This key represents the default locale for package meta-data. The format is BCP-47. This value identifies the language for meta-data to be displayed to a user when no locale file matching their preferences is available. The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules for that corresponding locale file.

ManifestType

The manifest type

Required Field

This key must have the value "version". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion

The manifest syntax version

Required Field

This key must have the value "1.0.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.1.0 DefaultLocale (`doc/manifest/schema/1.1.0/defaultLocale.md`)

Windows Package Manager

Manifest Schema v1.1.0 Default Locale File

Default Locale Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

The current best practice for the Windows Package Manager 1.2 client is to use the value reported in Windows Apps & Features when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior.

PackageLocaleThe package meta-data locale

Required Field

References:

Available languages for Windows
Default Input Profiles (Input Locales) in Windows

Note: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Required Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

Note: With the 1.2 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP) and Windows Apps & Features respectively. The best practice is to ensure this matches the entry for the package when it has been installed. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package. In other cases this may be a URL pointing to the contributors web page for a package.

PackageName - The package name

Required Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

Note: With the 1.2 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Required Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Required Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

Note: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

Note: This was included for integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker - The most common package term

Optional Field

This key represents the most common term users would search for when installing or upgrading a package. If only one package uses this moniker, then the install, list and upgrade command may match with this package.

Note:Moniker is the third property evaluated when searching for a matching package.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages. Tags should be pertinent to what a user might search for when looking for a specific package.

Note: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Windows Package Manager Community Repository

Agreements are only allowed in the community repository when the manifest is maintained by a verified developer.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Optional Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

ManifestType - The manifest type

Required Field

This key must have the value "defaultLocale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.1.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.1.0 Installer (`doc/manifest/schema/1.1.0/installer.md`)

Windows Package Manager

Manifest Schema v1.1.0 Installer File

Note: The 1.1 manifest schema was released with the Windows Package Manager 1.2. Any fields marked Not implemented are not supported in the 1.2 client, but may be supported in a 1.3-preview client.

Installer Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Installer Minimal Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Installers:
  - Architecture: x64
    InstallerType: msix
    InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
    InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
ManifestType: installer
ManifestVersion: 1.1.0

Installer Complex Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Platform:
- Windows.Desktop
MinimumOSVersion: 10.0.18362.0
InstallerType: msix
InstallModes:
- silent
PackageFamilyName: Microsoft.WindowsTerminal_8wekyb3d8bbwe
Installers:
- Architecture: x64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: arm64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: x86
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
ManifestType: installer
ManifestVersion: 1.1.0

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

Note: The current best practice is to use the value reported in Add / Remove Programs when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior. This practice may seem contrary to using semantic versioning, but it provides the best end to end experience for customers. It will take time for publishers and ISVs to migrate to semantic versioning, and some may intentionally choose to preserve other versioning schemes. In these cases, it is best practice to include the "AppsAndFeaturesEntries" section for each installer.

Channel - The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

Note: This key is included for future use. The Windows Package Manager currently does not have any behavior associated with this key. The intent behind this key is to help disambiguate the different channels for packages lacking support for side by side installation. Some packages support having more than one package channel available on a system simultaneously; in this case it is better to use unique packages rather than channels. This key is intended to ensure the proper channel for a package is used during install and upgrade scenarios.

Installers - Package installer

Required Field

The key represents an installer for a package.

Note: Many of the keys related to installers may either be at the root level of the manifest, or included in an installer. Any values provided at the root level and not specified in an installer will be inherited.

Architecture - The installer target architecture

Required Field

InstallerLocale - Locale for package installer

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Platform - The installer supported operating system

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

MinimumOSVersion - The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerType - Enumeration of supported installer types.

Required Field

Note: The Windows Package Manager defaults to the install mode providing install progress. A best practice is to determine if one of the supported installer technologies was used to build an installer with the .exe file extension. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension.

Note: The Windows Package Manager 1.2 does not support loose executables with the .exe or .com file extension directly. Compressed files containing installers, loose executables, and Progressive Web Applications (PWAs) are also not supported.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerUrl - The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256 - Sha256 is required. Sha256 of the installer

Required Field

Note: The Windows Package Manager Manifest Creator can be used to determine the SHA 256 of the installer. The winget hash <pathToInstaller> command can also be used to determine the SHA 256 of the installer.

SignatureSha256 - SignatureSha256 is recommended for appx or msix. It is the sha256 of signature file inside appx or msix. Could be used during streaming install if applicable

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

Note: MSIX installers must be signed to be included in the Microsoft community package repository. If the installer is an MSIX this signature should be included in the manifest. The Windows Package Manager Manifest Creator can be used to determine the signature SHA 256. The winget hash --msix command can also be used to determine the signature SHA 256.

Scope - Scope indicates if the installer is per user or per machine

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallModes - List of supported installer modes

Optional Field

Note: Some installers will attempt to install missing dependencies. If these dependencies require user interaction, the package will not be allowed into the Microsoft community package repository.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerSwitches - Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

Windows Package Manager Community Repository

The Microsoft community repository currently requires support for silent and silent with progress installation. Many custom .exe installers will require the proper switches to meet this requirement. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension. In the event the tool is unable to determine the tool used to build the installer, the publisher may have documentation for the proper switches.

Silent - Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

Note: When the Windows Package Manager installs a package using the "silent" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

SilentWithProgress - SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

Note: When the Windows Package Manager installs a package using the "silent with progress" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Interactive - Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

Note: When the Windows Package Manager installs a package using the "interactive" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

InstallLocation - InstallLocation is the value passed to the installer for custom install location.

Optional Field

Log - Log is the value passed to the installer for custom log file path.

Optional Field

Upgrade - Upgrade is the value that should be passed to the installer when user chooses an upgrade.

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom - Custom switches will be passed directly to the installer by the Windows Package Manager.

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

UpgradeBehavior - The upgrade method

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Commands - List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

Note: The Windows Package Manager does not update the path during the install workflow. In those cases, the user may need to restart their shell or terminal before the command will execute the newly installed package. The Windows Package Manager does not support any behavior related to commands or aliases.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Protocols - List of protocols the package provides a handler for

Optional Field

This key represents any protocols supported by the package. The Windows Package Manager does not support any behavior related to protocols handled by a package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

FileExtensions - List of file extensions the package could support

Optional Field

This key represents any file extensions supported by the package. The Windows Package Manager does not support any behavior related to the file extensions supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Dependencies - List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

ExternalDependencies - List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageDependencies - List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

WindowsFeatures - List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

WindowsLibraries - List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageFamilyName - PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Capabilities - List of appx or msix installer capabilities

Optional Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

RestrictedCapabilities - List of appx or msix installer restricted capabilities

Optional Field

This key represents the restricted capabilities provided by an MSIX package. More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerAbortsTerminal - Indicator for installers that abort the terminal.

Optional Field

This key represents the behavior associated with installers that abort the terminal. This most often occurs when a user is performing an upgrade of the running terminal.

Note: Windows Terminal no longer causes this to occur as the MSIX install behavior from the Windows Package Manager is deferred registration.

InstallLocationRequired - Indicator for packages requiring an install location to be specified.

Optional Field

This key represents the requirement to have an install location specified. These installers are known to deploy files to the location the installer is executed in.

Note: The behavior associated with this key is not implemented in the Windows Package Manager 1.2 client.

RequireExplicitUpgrade - Indicator for packages that upgrade themselves.

Optional Field

This key identifies packages that upgrade themselves. By default, they are excluded from winget upgrade --all.

ElevationRequirement - Indicator for elevation requirements when installing or upgrading packages.

Optional Field

This key represents which scope a package is required to be executed under. Some packages require user level execution while others require administrative level execution.

Note: The behavior associated with this key is not implemented in the Windows Package Manager 1.2 client.

UnsupportedOSArchitectures - List of unsupported architectures for a package.

Optional Field

This key represents any architectures a package is known not to be compatible with. Generally, this is associated with emulation modes.

Markets - List of supported markets for a package.

Optional Field

This key represents any markets a package may be installed in.

Note: If a market is listed in both this key and the ExcludedMarkets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

ExcludedMarkets - List of unsupported markets for a package.

Optional Field

This key represents any markets a package may not be installed in.

Note: If a market is listed in both this key and the Markets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

InstallerSuccessCodes - List of additional non-zero installer success exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

Note: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

ExpectedReturnCodes - List of additional non-zero installer exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a condition other than zero.

Note: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerReturnCode - The non-zero installer exit code other than known default values by the Windows Package Manager.

Optional Field

This key represents any status code returned by the installer representing a condition other than zero. MSIX and MSI packages have well known return codes. This is primarily intended for executable installers that have custom or unique return codes that can be mapped to a return response.

ReturnResponse - The return response to be displayed in the event an expected return code is encountered.

Optional Field

This key represents a return response to display when an installer returns an expected return code. MSIX and MSI packages have well known return codes. This is primarily intended for executable installers that have custom or unique return codes that can be mapped to a return response.

Note: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ProductCode - ProductCode is used for correlation of packages with manifests is configured sources.

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

AppsAndFeaturesEntries - AppsAndFeaturesEntries are used to match installed packages with manifests in configured sources.

Optional Field

This key represents the values reported by Windows Apps & Features. When a package is installed, entries are made into the Windows Registry.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

DisplayName - DisplayName is what is displayed in the Control Panel for installed packages.

Optional Field

This key represents the package name as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

DisplayVersion - DisplayVersion is the version displayed in the Control Panel for installed packages.

Optional Field

This key represents the package version as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

Publisher - Publisher is the value of the package publisher reported in the Windows registry.

Optional Field

This key represents the Publisher reported in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the product code for a package. It is used to help correlate installed packages with manifests in configured sources.

Note: This key is displayed twice for completeness. As the AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client, the description and usage above is implemented.

UpgradeCode - UpgradeCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the upgrade code for a package. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

InstallerType - Enumeration of supported installer types.

Optional Field

This key represents the installer type for the package. It is used to help correlate installed packages with manifests in configured sources. In some cases, an installer is an .exe based installer, but contains an MSI installer. This key will help the Windows Package Manager understand if upgrading an MSI should be performed when it is contained in an .exe installer.

Note: This key is displayed twice for completeness. As the AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client, the description and usage above is implemented.

ReleaseDate - The Release Date for a package.

Optional Field

This key represents the release date for a package.

ManifestType - The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.1.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.1.0 Locale (`doc/manifest/schema/1.1.0/locale.md`)

Windows Package Manager

Manifest Schema v1.1.0 Locale File

Locale Manifest

yaml

PackageIdentifier:            # The package unique identifier
PackageVersion:               # The package version
PackageLocale:                # The package meta-data locale
Publisher:                    # Optional publisher name
PublisherUrl:                 # Optional publisher home page
PublisherSupportUrl:          # Optional publisher support page
PrivacyUrl:                   # Optional publisher privacy page
Author:                       # Optional author
PackageName:                  # Optional package name
PackageUrl:                   # Optional package home page
License:                      # Optional package license
LicenseUrl:                   # Optional package license page
Copyright:                    # Optional package copyright
CopyrightUrl:                 # Optional package copyright page
ShortDescription:             # Optional short package description
Description:                  # Optional full package description
Tags:                         # Optional list of package terms
Agreements:                   # Optional package agreements
  - AgreementLabel:           # Optional agreement label
    Agreement:                # Optional agreement text
    AgreementUrl:             # Optional agreement URL
ReleaseNotes:                 # Optional release notes
ReleaseNotesUrl:              # Optional release notes URL
ManifestType: locale          # The manifest type
ManifestVersion: 1.1.0        # The manifest syntax version

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

PackageLocale - The package meta-data locale

Required Field

References

Available languages for Windows
Default Input Profiles (Input Locales) in Windows

Note: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Optional Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

Note: With the 1.1 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package when it has been installed. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package, it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package.

PackageName - The package name

Optional Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

Note: With the 1.1 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Optional Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package, it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package, it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Optional Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

Note: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

Note: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages.

Note: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Note: In the Windows Package Manager Community Repository, these are only allowed to be submitted by verified developers.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Optional Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

ManifestType - The manifest type

Required Field

This key must have the value "locale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.1.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.1.0 Singleton (`doc/manifest/schema/1.1.0/singleton.md`)

Minimal singleton YAML file example

As specified in the singleton JSON schema, only a number of fields are required. The singleton format is only valid for packages containing a single installer and a single locale. If more than one installer or locale is provided, the multiple YAML file format and schema must be used.

Note: The singleton manifest format has been deprecated in the Windows Package Manager Community Repository. The Windows Package Manager 1.2 client still supports singleton manifests.

Singleton Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

[Singleton Minimal Example](#tab/minimal/)

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.6.10571.0
PackageLocale: en-US
Publisher: Microsoft
PackageName: Windows Terminal
License: MIT
ShortDescription: The new Windows Terminal, a tabbed command line experience for Windows.
Installers:
 - Architecture: x64
   InstallerType: msix
   InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.6.10571.0/Microsoft.WindowsTerminal_1.6.10571.0_8wekyb3d8bbwe.msixbundle
   InstallerSha256: 092aa89b1881e058d31b1a8d88f31bb298b5810afbba25c5cb341cfa4904d843
   SignatureSha256: e53f48473621390c8243ada6345826af7c713cf1f4bbbf0d030599d1e4c175ee
ManifestType: singleton
ManifestVersion: 1.1.0

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

Note: The current best practice is to use the value reported in Add / Remove Programs when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior. This practice may seem contrary to using semantic versioning, but it provides the best end to end experience for customers. It will take time for publishers and ISVs to migrate to semantic versioning, and some may intentionally choose to preserve other versioning schemes. In these cases, it is best practice to include the "AppsAndFeaturesEntries" section for each installer.

Channel - The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

Note: This key is included for future use. The Windows Package Manager currently does not have any behavior associated with this key. The intent behind this key is to help disambiguate the different channels for packages lacking support for side by side installation. Some packages support having more than one package channel available on a system simultaneously; in this case it is better to use unique packages rather than channels. This key is intended to ensure the proper channel for a package is used during install and upgrade scenarios.

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

Note: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker - The most common package term

Optional Field

Note:Moniker is the third property evaluated when searching for a matching package.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages.

Note: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Note: In the Windows Package Manager Community Repository, these are only allowed to be submitted by verified developers.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Optional Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

ReleaseDate - The Release Date for a package.

Optional Field

This key represents the release date for a package.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

Installers - Package installer

Required Field

The key represents an installer for a package.

Note: Many of the keys related to installers may either be at the root level of the manifest, or included in an installer. Any values provided at the root level and not specified in an installer will be inherited.

Architecture - The installer target architecture

Required Field

InstallerLocale - Locale for package installer

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Platform - The installer supported operating system

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

MinimumOSVersion - The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerType - Enumeration of supported installer types.

Required Field

Note: The Windows Package Manager defaults to the install mode providing install progress. A best practice is to determine if one of the supported installer technologies was used to build an installer with the .exe file extension. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension.

Note: The Windows Package Manager does not support loose executables with the .exe or .com file extension directly. Compressed files containing installers, loose executables, and Progressive Web Applications (PWAs) are also not supported.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerUrl - The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256 - Sha256 is required. Sha256 of the installer

Required Field

Note: The Windows Package Manager Manifest Creator can be used to determine the SHA 256 of the installer. The winget hash <pathToInstaller> command can also be used to determine the SHA 256 of the installer.

SignatureSha256 - SignatureSha256 is recommended for appx or msix. It is the sha256 of the signature file inside the appx or msix. Could be used during streaming install if applicable.

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

Note: MSIX installers must be signed to be included in the Microsoft community package repository. If the installer is an MSIX this signature should be included in the manifest. The Windows Package Manager Manifest Creator can be used to determine the signature SHA 256. The winget hash --msix command can also be used to determine the signature SHA 256.

Scope - Scope indicates if the installer is per user or per machine

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallModes - List of supported installer modes

Optional Field

Note: Some installers will attempt to install missing dependencies. If these dependencies require user interaction, the package will not be allowed into the Microsoft community package repository.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerSwitches - Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

Note: The Microsoft community repository currently requires support for silent and silent with progress installation. Many custom .exe installers will require the proper switches to meet this requirement. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension. In the event the tool is unable to determine the tool used to build the installer, the publisher may have documentation for the proper switches.

Silent - Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

Note: When the Windows Package Manager installs a package using the "silent" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

SilentWithProgress - SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

Note: When the Windows Package Manager installs a package using the "silent with progress" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Interactive - Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

Note: When the Windows Package Manager installs a package using the "interactive" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

InstallLocation - InstallLocation is the value passed to the installer for custom install location.

Optional Field

Log - Log is the value passed to the installer for custom log file path.

Optional Field

Upgrade - Upgrade is the value that should be passed to the installer when user chooses an upgrade.

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom - Custom switches will be passed directly to the installer by the Windows Package Manager.

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

Note: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

UpgradeBehavior - The upgrade method

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Commands - List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

Note: The Windows Package Manager does not update the path during the install workflow. In those cases, the user may need to restart their shell or terminal before the command will execute the newly installed package. The Windows Package Manager does not support any behavior related to commands or aliases.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Protocols - List of protocols the package provides a handler for

Optional Field

This key represents any protocols supported by the package. The Windows Package Manager does not support any behavior related to protocols handled by a package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

FileExtensions - List of file extensions the package could support

Optional Field

This key represents any file extensions supported by the package. The Windows Package Manager does not support any behavior related to the file extensions supported by the package.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Dependencies - List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

ExternalDependencies - List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageDependencies - List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

WindowsFeatures - List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

WindowsLibraries - List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

Note: The Windows Package Manager does not support any behavior related to dependencies.

PackageFamilyName - PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Capabilities - List of appx or msix installer capabilities

Optional Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

RestrictedCapabilities - List of appx or msix installer restricted capabilities

Optional Field

This key represents the restricted capabilities provided by an MSIX package.More information is available for App capability declarations

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerAbortsTerminal - Indicator for installers that abort the terminal.

Optional Field

This key represents the behavior associated with installers that abort the terminal. This most often occurs when a user is performing an upgrade of the running terminal.

Note: Windows Terminal no longer causes this to occur as the MSIX install behavior from the Windows Package Manager is deferred registration.

InstallLocationRequired - Indicator for packages requiring an install location to be specified.

Optional Field

This key represents the requirement to have an install location specified. These installers are known to deploy files to the location the installer is executed in.

Note: The behavior associated with this key is not implemented in the Windows Package Manager 1.2 client.

RequireExplicitUpgrade - Indicator for packages that upgrade themselves.

Optional Field

This key identifies packages that upgrade themselves. By default, they are excluded from winget upgrade --all.

ElevationRequirement - Indicator for elevation requirements when installing or upgrading packages.

Optional Field

This key represents which scope a package is required to be executed under. Some packages require user level execution while others require administrative level execution.

Note: The behavior associated with this key is not implemented in the Windows Package Manager 1.2 client.

UnsupportedOSArchitectures - List of unsupported architectures for a package.

Optional Field

This key represents any architectures a package is known not to be compatible with. Generally, this is associated with emulation modes.

Markets - List of supported markets for a package.

Optional Field

This key represents any markets a package may be installed in.

Note: If a market is listed in both this key and the ExcludedMarkets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

ExcludedMarkets - List of unsupported markets for a package.

Optional Field

This key represents any markets a package may not be installed in.

Note: If a market is listed in both this key and the Markets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

InstallerSuccessCodes - List of additional non-zero installer success exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

Note: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

ExpectedReturnCodes - List of additional non-zero installer exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a condition other than zero.

Note: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

InstallerReturnCode - The non-zero installer exit code other than known default values by the Windows Package Manager.

Optional Field

ReturnResponse - The return response to be displayed in the event an expected return code is encountered.

Optional Field

Note: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

Note: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

AppsAndFeaturesEntries - AppsAndFeaturesEntries are used to match installed packages with manifests in configured sources.

Optional Field

This key represents the values reported by Windows Apps & Features. When a package is installed, entries are made into the Windows Registry.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

DisplayName - DisplayName is what is displayed in the Control Panel for installed packages.

Optional Field

This key represents the package name as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

DisplayVersion - DisplayVersion is the version displayed in the Control Panel for installed packages.

Optional Field

This key represents the package version as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

Publisher - Publisher is the value of the package publisher reported in the Windows registry.

Optional Field

This key represents the Publisher reported in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the product code for a package. It is used to help correlate installed packages with manifests in configured sources.

Note: This key is displayed twice for completeness. As the AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client, the description and usage above is implemented.

UpgradeCode - UpgradeCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the upgrade code for a package. It is used to help correlate installed packages with manifests in configured sources.

Note: The AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client.

InstallerType - Enumeration of supported installer types.

Optional Field

Note: This key is displayed twice for completeness. As the AppsAndFeatures behavior is not implemented in the Windows Package Manager 1.2 client, the description and usage above is implemented.

ManifestType - The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.1.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.1.0 Version (`doc/manifest/schema/1.1.0/version.md`)

Windows Package Manager

Manifest Schema v1.1.0 Version File

Version Manifest

yaml

PackageIdentifier:      # The package unique identifier
PackageVersion:         # The package version
DefaultLocale:          # The default package meta-data locale
ManifestType: version   # The manifest type
ManifestVersion: 1.1.0  # The manifest syntax version

Fields

PackageIdentifier - The package unique identifier

Required Field

This key is the unique identifier for a given package.

Windows Package Manager Community Repository

This value is generally in the form of Publisher.Package. It is case sensitive, and this value must match the folder structure under the partition directory.

PackageVersion - The package version

Required Field

DefaultLocale - The default package meta-data locale

Required Field

Windows Package Manager Community Repository

The validation pipelines use this value to ensure the corresponding locale file is present and conforms with the defaultLocale YAML specification.

ManifestType - The manifest type

Required Field

This key must have the value "version". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field
This key must have the value "1.1.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.10.0 DefaultLocale (`doc/manifest/schema/1.10.0/defaultLocale.md`)

Windows Package Manager

Manifest Schema v1.10.0 Default Locale File

Default Locale Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

The current best practice for the Windows Package Manager 1.10 client is to use the value reported in Windows Apps & Features when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior.

PackageLocale - The package meta-data locale

Required Field

References:

Available languages for Windows
Default Input Profiles (Input Locales) in Windows

NOTE: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Required Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

NOTE: With the 1.10 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP) and Windows Apps & Features respectively. The best practice is to ensure this matches the entry for the package when it has been installed. This should be the value of the Publisher subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package. In other cases this may be a URL pointing to the contributors web page for a package.

PackageName - The package name

Required Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

NOTE: With the 1.10 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. This should be the value of the DisplayName subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Required Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Required Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

The value must be at least 3 characters long, and at most 256 characters long.

NOTE: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

NOTE: This was included for integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker - The most common package term

Optional Field

This key represents the most common term users would search for when installing or upgrading a package. If only one package uses this moniker, then the install, list and upgrade command may match with this package.

NOTE: Moniker is the third property evaluated when searching for a matching package.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages. Tags should be pertinent to what a user might search for when looking for a specific package.

A maximum of 16 tags can be added.

NOTE: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Windows Package Manager Community Repository

Agreements are only allowed in the community repository when the manifest is maintained by a verified developer.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Restricted Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

Documentations - List of documentation

Optional Field

This key holds any documentation for providing software guides such as manuals and troubleshooting URLs.

DocumentLabel - The documentation label

Optional Field

This key represents the label for a documentation.

DocumentUrl - List of documentation

Optional Field

This key represents the URL for a documentation.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

PurchaseUrl - The Purchase URL for a package.

Optional Field

This key represents the purchase url for acquiring entitlement for a package.

InstallationNotes - The Installation Notes for a package.

Optional Field

This key represents the notes displayed to the user upon completion of a package installation.

ManifestType - The manifest type

Required Field

This key must have the value "defaultLocale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.10.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.10.0 Installer (`doc/manifest/schema/1.10.0/installer.md`)

Windows Package Manager

Manifest Schema v1.10.0 Installer File

[!IMPORTANT]
The 1.10 manifest schema was released with the Windows Package Manager 1.10. Any fields marked Not implemented are not supported in the 1.10 client, but may be supported in newer versions of the client.

Installer Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Installer Minimal Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Installers:
  - Architecture: x64
    InstallerType: msix
    InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
    InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
ManifestType: installer
ManifestVersion: 1.10.0

Installer Complex Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Platform:
- Windows.Desktop
MinimumOSVersion: 10.0.18362.0
InstallerType: msix
InstallModes:
- silent
PackageFamilyName: Microsoft.WindowsTerminal_8wekyb3d8bbwe
Installers:
- Architecture: x64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: arm64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: x86
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
ManifestType: installer
ManifestVersion: 1.10.0

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

NOTE: The current best practice is to use the value reported in Add / Remove Programs when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior. This practice may seem contrary to using semantic versioning, but it provides the best end to end experience for customers. It will take time for publishers and ISVs to migrate to semantic versioning, and some may intentionally choose to preserve other versioning schemes. In these cases, it is best practice to include the "AppsAndFeaturesEntries" section for each installer.

Channel - The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

NOTE: This key is included for future use. The Windows Package Manager currently does not have any behavior associated with this key. The intent behind this key is to help disambiguate the different channels for packages lacking support for side by side installation. Some packages support having more than one package channel available on a system simultaneously; in this case it is better to use unique packages rather than channels. This key is intended to ensure the proper channel for a package is used during install and upgrade scenarios.

Installers - Package installer

Required Field

The key represents an installer for a package.

IMPORTANT: Many of the keys related to installers may either be at the root level of the manifest, or included in an installer. Any values provided at the root level and not specified in an installer will be inherited.

Architecture - The installer target architecture

Required Field

Available architectures:

x86
x64
arm
arm64
neutral

InstallerLocale - Locale for package installer

Optional Field

NOTE: This key may be present in the root of the manifest as the default value for all installer nodes. This key may also be present in an individual installer node as well. If this key is in the manifest root and in an installer node, the value in the installer node will apply.

Platform - The installer supported operating system

Optional Field

MinimumOSVersion - The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

InstallerType - Enumeration of supported installer types.

Required Field

This key represents the installer type for the package. The Windows Package Manager supports MSIX, MSI, and executable installers. Some well known formats (Inno, Nullsoft, WiX, and Burn) provide standard sets of installer switches to provide different installer experiences. Portable packages are supported as of Windows Package Manager 1.3. Zip packages are supported as of Windows Package Manager 1.5.

IMPORTANT: The Windows Package Manager 1.10 does not support loose executables with the .com file extension directly. Progressive Web Applications (PWAs) and fonts are also not supported.

NOTE: The Windows Package Manager defaults to the install mode providing install progress. A best practice is to determine if one of the supported installer technologies was used to build an installer with the .exe file extension. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension.

InstallerUrl - The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256 - Sha256 is required. Sha256 of the installer

Required Field

NOTE: The Windows Package Manager Manifest Creator can be used to determine the SHA 256 of the installer. The winget hash <pathToInstaller> command can also be used to determine the SHA 256 of the installer.

SignatureSha256 - SignatureSha256 is recommended for appx or msix. It is the sha256 of signature file inside appx or msix. Could be used during streaming install if applicable

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

IMPORTANT: MSIX installers must be signed to be included in the Microsoft community package repository. If the installer is an MSIX this signature should be included in the manifest. The Windows Package Manager Manifest Creator can be used to determine the signature SHA 256. The winget hash --msix command can also be used to determine the signature SHA 256.

NestedInstallerType - NestedInstallerType is required when InstallerType is an archive type such as '.zip'

Required Field

This key represents the installer type of the file within the archive which will be used as the installer.

NestedInstallerFiles - NestedInstallerFiles is required when InstallerType is an archive type such as '.zip'

Required Field

This key is a list of all the installers to be executed within an archive.

IMPORTANT: This field can only contain one nested installer file unless the NestedInstallerType is 'portable'

RelativeFilePath - RelativeFilePath is required within NestedInstallerFiles

Required Field

The relative path to the installer file contained within the archive.

PortableCommandAlias - The command alias to be used for calling the package

Optional Field

The alias which is added to the PATH for calling the package from the command line.

IMPORTANT: This field is only valid when NestedInstallerType is 'portable'

Scope - Scope indicates if the installer is per user or per machine

Optional Field

InstallModes - List of supported installer modes

Optional Field

IMPORTANT: Some installers will attempt to install missing dependencies. If these dependencies require user interaction, the package will not be allowed into the Microsoft community package repository.

InstallerSwitches - Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

Windows Package Manager Community Repository

Silent - Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

NOTE: When the Windows Package Manager installs a package using the "silent" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

SilentWithProgress - SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

NOTE: When the Windows Package Manager installs a package using the "silent with progress" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Interactive - Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

NOTE: When the Windows Package Manager installs a package using the "interactive" install mode, any custom switches will also be passed to the installer. If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

InstallLocation - InstallLocation is the value passed to the installer for custom install location.

Optional Field

Log - Log is the value passed to the installer for custom log file path.

Optional Field

Upgrade - Upgrade is the value that should be passed to the installer when user chooses an upgrade.

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom - Custom switches will be passed directly to the installer by the Windows Package Manager.

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Repair - Repair is the value that should be passed to the installer when a user chooses to repair an existing installation

Optional Field

This key represents the switches to be passed during the repair of an existing installation. This will be passed to the installer, ModifyPath ARP command, or Uninstaller ARP command depending on the RepairBehavior specified in the manifest.

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

UpgradeBehavior - The upgrade method

Optional Field

Commands - List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

IMPORTANT: The Windows Package Manager does not update the path during the install workflow. In those cases, the user may need to restart their shell or terminal before the command will execute the newly installed package. The Windows Package Manager does not support any behavior related to commands or aliases.

Protocols - List of protocols the package provides a handler for

Optional Field

This key represents any protocols (i.e. URI schemes) supported by the package. For example: ["ftp", "ldap"]. Entries shouldn't have trailing colons. The Windows Package Manager does not support any behavior related to protocols handled by a package.

FileExtensions - List of file extensions the package could support

Optional Field

This key represents any file extensions supported by the package. For example: ["html", "jpg"]. Entries shouldn't have leading dots. The Windows Package Manager does not support any behavior related to the file extensions supported by the package.

Dependencies - List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

IMPORTANT: External Dependencies are not supported. Package dependencies are referenced by their package identifier and must come from the same source. Windows Features may require a reboot before they are enabled. Windows Libraries are not supported.

ExternalDependencies - List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to external dependencies.

PackageDependencies - List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

IMPORTANT: Dependencies are referenced by their package identifier and must come from the same source.

WindowsFeatures - List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

WindowsLibraries - List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to Windows Libraries.

PackageFamilyName - PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

Capabilities - List of appx or msix installer capabilities

Restricted Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

RestrictedCapabilities - List of appx or msix installer restricted capabilities

Restricted Field

This key represents the restricted capabilities provided by an MSIX package. More information is available for App capability declarations

InstallerAbortsTerminal - Indicator for installers that abort the terminal.

Optional Field

This key represents the behavior associated with installers that abort the terminal. This most often occurs when a user is performing an upgrade of the running terminal.

NOTE: Windows Terminal no longer causes this to occur as the MSIX install behavior from the Windows Package Manager is deferred registration.

InstallLocationRequired - Indicator for packages requiring an install location to be specified.

Optional Field

This key represents the requirement to have an install location specified. These installers are known to deploy files to the location the installer is executed in.

RequireExplicitUpgrade - Indicator for packages that upgrade themselves.

Optional Field

This key identifies packages that upgrade themselves. By default, they are excluded from winget upgrade --all.

ElevationRequirement - Indicator for elevation requirements when installing or upgrading packages.

Optional Field

This key represents which scope a package is required to be executed under. Some packages require user level execution while others require administrative level execution.

elevationRequired - Must be run from a shell that is running in an administrative context (e.g - Admin user using powershell/terminal/cmd with "Run as Administrator")
elevationProhibited - Must be run from a shell that is not running in an administrative context
elevatesSelf - If called from a non-administrative context, will request elevation. If called from an administrative context, may or may not request elevation.

UnsupportedOSArchitectures - List of unsupported architectures for a package.

Optional Field

This key represents any architectures a package is known not to be compatible with. Generally, this is associated with emulation modes.

Markets - List of supported markets for a package.

Restricted Field

This key represents any markets a package may be installed in.

IMPORTANT: If a market is listed in both this key and the ExcludedMarkets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

ExcludedMarkets - List of unsupported markets for a package.

Restricted Field

This key represents any markets a package may not be installed in.

IMPORTANT: If a market is listed in both this key and the Markets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

InstallerSuccessCodes - List of additional non-zero installer success exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

IMPORTANT: Some return codes indicate a reboot is suggested or required. The Windows Package Manager does not support the reboot behavior currently. Some installers will force a reboot, and the Windows Package Manager does not currently suppress reboot behavior.

ExpectedReturnCodes - List of additional non-zero installer exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a condition other than zero.

InstallerReturnCode - The non-zero installer exit code other than known default values by the Windows Package Manager.

Optional Field

ReturnResponse - The return response to be displayed in the event an expected return code is encountered.

Optional Field

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ReturnResponseUrl - The return response URL to be displayed in the event an expected return code is encountered.

Optional Field

This key represents a return response URL to display when an installer returns an expected return code. MSIX and MSI packages have well known return codes. This is primarily intended for executable installers that have custom or unique return codes that can be mapped to a return response.

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ProductCode - ProductCode is used for correlation of packages with manifests is configured sources.

Optional Field

AppsAndFeaturesEntries - AppsAndFeaturesEntries are used to match installed packages with manifests in configured sources.

Optional Field

This key represents the values reported by Windows Apps & Features. When a package is installed, entries are made into the Windows Registry.

DisplayName - DisplayName is what is displayed in the Control Panel for installed packages.

Optional Field

This key represents the package name as displayed in Windows Apps & Features. This is the value of the DisplayName subkey for the package in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

DisplayVersion - DisplayVersion is the version displayed in the Control Panel for installed packages.

Optional Field

This key represents the package version as displayed in Windows Apps & Features. This is the value of the DisplayVersion subkey for the package in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

Note: When the PackageVersion and DisplayVersion are the same, the DisplayVersion should be omitted from the AppsAndFeaturesEntries

Publisher - Publisher is the value of the package publisher reported in the Windows registry.

Optional Field

This key represents the package publisher as displayed in Windows Apps & Features. This is the value of the Publisher subkey for the package in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the product code for a package. It is used to help correlate installed packages with manifests in configured sources.

NOTE: This key is displayed twice for completeness. When AppsAndFeaturesEntries are specified, the ProductCode should be placed both within the installer and the AppsAndFeaturesEntries

UpgradeCode - UpgradeCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the upgrade code for a package. It is used to help correlate installed packages with manifests in configured sources.

InstallerType - Enumeration of supported installer types.

Optional Field

NOTE: This key is displayed twice for completeness. When AppsAndFeaturesEntries are specified, the InstallerType should be placed within the installer only, unless the AppsAndFeaturesEntries represent a different InstallerType

UnsupportedArguments - List of unsupported Windows Package Manager Client arguments for an installer.

Optional Field

This key represents the list of Windows Package Manager Client arguments the installer does not support. Only the --log and --location arguments can be specified as unsupported arguments for an installer.

DisplayInstallWarnings - Indicator for displaying a warning message prior to install or upgrade.

Optional Field

This key represents whether a warning message is displayed to the user prior to install or upgrade if the package is known to interfere with any running applications.

NOTE: The DisplayInstallWarnings behavior is not implemented in the Windows Package Manager 1.10 client.

ReleaseDate - The Release Date for a package.

Optional Field

This key represents the release date for a package, in RFC 3339 / ISO 8601 format, i.e. "YYYY-MM-DD".

InstallationMetadata - Details about the installation.

Optional Field

This key allows for additional metadata to be used for deeper installation detection.

DefaultInstallLocation - The default installed package location.

Optional Field

This key represents the default install location for the package.

Files - The list of installed files.

Optional Field

This key represents the files installed for the package.

RelativeFilePath - The relative path to the installed file.

Optional Field

This key represents the path to the installed file relative to the default install location.

FileSha256 - The optional Sha256 of the installed file.

Optional Field

This key represents the Sha256 hash of the installed file.

FileType - The optional installed file type.

Optional Field

This key represents the type of the installed file - launch, uninstall, or other. If not specified, the file is treated as other.

InvocationParameter - Optional parameter for invocable files.

Optional Field

This key represents the parameter to use for invocable files.

DisplayName - Optional display name for invocable files

Optional Field

This key represents the display name to use for invocable files.

DownloadCommandProhibited - Optional indicator for packages which cannot be downloaded for offline installation

Optional Field

When true, this flag will prohibit the manifest from being downloaded for offline installation with the winget download command

RepairBehavior - Optional repair method to use with 'winget repair`

Optional Field

This field controls what method is used to repair existing installations of packages. Specifying modify will use the ModifyPath string from the package's ARP data, uninstaller will use the Uninstall string from the package's ARP data, and installer will download and run the installer. In each case, the Repair value from InstallerSwitches will be added as an argument when invoking the command to repair the package.

ArchiveBinariesDependOnPath - Optional indication to add the install location directly to PATH. Only applies to an archive containing portable packages

Optional Field

This field controls the behavior of environment variables when installing portable packages from an archive (i.e zip). Specifying true will add the install location directly to the PATH environment variable. Specifying false or leaving the value unset will use the default behavior of adding a symlink to the links folder, if supported, or adding the install location directly to PATH if symlinks are not supported.

text

**Authentication** - Authentication information for Entra Id secured private sources

Restricted Field

This field controls the authentication for Entra ID secured private sources. Authentication type is required. Resource and scope information can be included if a specific resource is needed to download or install the package.

text

**AuthenticationType** - What type of authentication to use for Entra Id authentication

Restricted Field

This field controls the whether to use no authentication, Entra ID, or Entra ID for Azure Blob Storage.

text

**MicrosoftEntraIdAuthenticationInfo** - Information required for Entra Id authentication in private sources

Restricted Field

This field controls the authentication details used when downloading or installing packages from Entra Id secured private sources.

text

**Resource** - The resource to use for Microsoft Entra Id authentication

Restricted Field

This field controls the resource which will be used when using Entra Id for downloading or installing packages

text

**Scope** - The scope of Microsoft Entra Id authentication for the resource

Restricted Field

This field controls the scope which will be used when using Entra Id for downloading or installing packages

ManifestType - The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.10.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.10.0 Locale (`doc/manifest/schema/1.10.0/locale.md`)

Windows Package Manager

Manifest Schema v1.10.0 Locale File

Locale Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

PackageLocale - The package meta-data locale

Required Field

References

Available languages for Windows
Default Input Profiles (Input Locales) in Windows

NOTE: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Optional Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

NOTE: With the 1.10 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package when it has been installed. This should be the value of the Publisher subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package, it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package.

PackageName - The package name

Optional Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

NOTE: With the 1.10 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. This should be the value of the DisplayName subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Optional Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package, it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package, it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Optional Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

NOTE: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

NOTE: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages.

NOTE: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

IMPORTANT: In the Windows Package Manager Community Repository, these are only allowed to be submitted by verified developers.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Restricted Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

Documentations - List of documentation

Optional Field

This key holds any documentation for providing software guides such as manuals and troubleshooting URLs.

DocumentLabel - The documentation label

Optional Field

This key represents the label for a documentation.

DocumentUrl - List of documentation

Optional Field

This key represents the URL for a documentation.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

PurchaseUrl - The Purchase URL for a package.

Optional Field

This key represents the purchase url for acquiring entitlement for a package.

InstallationNotes - The Installation Notes for a package.

Optional Field

This key represents the notes displayed to the user upon completion of a package installation.

ManifestType - The manifest type

Required Field

This key must have the value "locale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.10.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.10.0 Singleton (`doc/manifest/schema/1.10.0/singleton.md`)

Minimal singleton YAML file example

[!WARNING]
The singleton manifest format has been deprecated in the Windows Package Manager Community Repository. The Windows Package Manager 1.10 client still supports singleton manifests.

Singleton Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

[Singleton Minimal Example](#tab/minimal/)

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.6.10571.0
PackageLocale: en-US
Publisher: Microsoft
PackageName: Windows Terminal
License: MIT
ShortDescription: The new Windows Terminal, a tabbed command line experience for Windows.
Installers:
 - Architecture: x64
   InstallerType: msix
   InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.6.10571.0/Microsoft.WindowsTerminal_1.6.10571.0_8wekyb3d8bbwe.msixbundle
   InstallerSha256: 092aa89b1881e058d31b1a8d88f31bb298b5810afbba25c5cb341cfa4904d843
   SignatureSha256: e53f48473621390c8243ada6345826af7c713cf1f4bbbf0d030599d1e4c175ee
ManifestType: singleton
ManifestVersion: 1.10.0

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

Channel - The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

NOTE: This was included for future integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker - The most common package term

Optional Field

NOTE: Moniker is the third property evaluated when searching for a matching package.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages.

NOTE: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

IMPORTANT: In the Windows Package Manager Community Repository, these are only allowed to be submitted by verified developers.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Restricted Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

Documentations - List of documentation

Optional Field

This key holds any documentation for providing software guides such as manuals and troubleshooting URLs.

DocumentLabel - The documentation label

Optional Field

This key represents the label for a documentation.

DocumentUrl - List of documentation

Optional Field

This key represents the URL for a documentation.

ReleaseDate - The Release Date for a package.

Optional Field

This key represents the release date for a package, in RFC 3339 / ISO 8601 format, i.e. "YYYY-MM-DD".

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

PurchaseUrl - The Purchase URL for a package.

Optional Field

This key represents the purchase url for acquiring entitlement for a package.

InstallationNotes - The Installation Notes for a package.

Optional Field

This key represents the notes displayed to the user upon completion of a package installation.

Installers - Package installer

Required Field

The key represents an installer for a package.

Architecture - The installer target architecture

Required Field

InstallerLocale - Locale for package installer

Optional Field

Platform - The installer supported operating system

Optional Field

MinimumOSVersion - The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

InstallerType - Enumeration of supported installer types.

Required Field

IMPORTANT: The Windows Package Manager does not support loose executables with the .exe or .com file extension directly. Progressive Web Applications (PWAs) and fonts are also not supported.

InstallerUrl - The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256 - Sha256 is required. Sha256 of the installer

Required Field

SignatureSha256 - SignatureSha256 is recommended for appx or msix. It is the sha256 of the signature file inside the appx or msix. Could be used during streaming install if applicable.

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

NestedInstallerType - NestedInstallerType is required when InstallerType is an archive type such as '.zip'

Required Field

This key represents the installer type of the file within the archive which will be used as the installer.

NestedInstallerFiles - NestedInstallerFiles is required when InstallerType is an archive type such as '.zip'

Required Field

This key is a list of all the installers to be executed within an archive.

Note: This field can only contain one nested installer file unless the NestedInstallerType is 'portable'

RelativeFilePath - RelativeFilePath is required within NestedInstallerFiles

Required Field

The relative path to the installer file contained within the archive.

PortableCommandAlias - The command alias to be used for calling the package

Required Field

The alias which is added to the PATH for calling the package from the command line.

Note: This field is only valid when NestedInstallerType is 'portable'

Scope - Scope indicates if the installer is per user or per machine

Optional Field

InstallModes - List of supported installer modes

Optional Field

InstallerSwitches - Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

IMPORTANT: The Microsoft community repository currently requires support for silent and silent with progress installation. Many custom .exe installers will require the proper switches to meet this requirement. The Windows Package Manager Manifest Creator tool can be used to determine if one of the known tools was used to build an installer with the .exe file extension. In the event the tool is unable to determine the tool used to build the installer, the publisher may have documentation for the proper switches.

Silent - Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

SilentWithProgress - SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

Interactive - Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

InstallLocation - InstallLocation is the value passed to the installer for custom install location.

Optional Field

Log - Log is the value passed to the installer for custom log file path.

Optional Field

Upgrade - Upgrade is the value that should be passed to the installer when user chooses an upgrade.

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom - Custom switches will be passed directly to the installer by the Windows Package Manager.

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Repair - Repair is the value that should be passed to the installer when a user chooses to repair an existing installation

Optional Field

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

UpgradeBehavior - The upgrade method

Optional Field

Commands - List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

Protocols - List of protocols the package provides a handler for

Optional Field

This key represents any protocols supported by the package. The Windows Package Manager does not support any behavior related to protocols handled by a package.

FileExtensions - List of file extensions the package could support

Optional Field

This key represents any file extensions supported by the package. The Windows Package Manager does not support any behavior related to the file extensions supported by the package.

Dependencies - List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to dependencies.

ExternalDependencies - List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to dependencies.

PackageDependencies - List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to dependencies.

WindowsFeatures - List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to dependencies.

WindowsLibraries - List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to dependencies.

PackageFamilyName - PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

Capabilities - List of appx or msix installer capabilities

Restricted Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

RestrictedCapabilities - List of appx or msix installer restricted capabilities

Restricted Field

This key represents the restricted capabilities provided by an MSIX package.More information is available for App capability declarations

InstallerAbortsTerminal - Indicator for installers that abort the terminal.

Optional Field

This key represents the behavior associated with installers that abort the terminal. This most often occurs when a user is performing an upgrade of the running terminal.

NOTE: Windows Terminal no longer causes this to occur as the MSIX install behavior from the Windows Package Manager is deferred registration.

InstallLocationRequired - Indicator for packages requiring an install location to be specified.

Optional Field

This key represents the requirement to have an install location specified. These installers are known to deploy files to the location the installer is executed in.

RequireExplicitUpgrade - Indicator for packages that upgrade themselves.

Optional Field

This key identifies packages that upgrade themselves. By default, they are excluded from winget upgrade --all.

ElevationRequirement - Indicator for elevation requirements when installing or upgrading packages.

Optional Field

This key represents which scope a package is required to be executed under. Some packages require user level execution while others require administrative level execution.

UnsupportedOSArchitectures - List of unsupported architectures for a package.

Optional Field

This key represents any architectures a package is known not to be compatible with. Generally, this is associated with emulation modes.

Markets - List of supported markets for a package.

Restricted Field

This key represents any markets a package may be installed in.

IMPORTANT: If a market is listed in both this key and the ExcludedMarkets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

ExcludedMarkets - List of unsupported markets for a package.

Restricted Field

This key represents any markets a package may not be installed in.

IMPORTANT: If a market is listed in both this key and the Markets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

InstallerSuccessCodes - List of additional non-zero installer success exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

ExpectedReturnCodes - List of additional non-zero installer exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a condition other than zero.

InstallerReturnCode - The non-zero installer exit code other than known default values by the Windows Package Manager.

Optional Field

ReturnResponse - The return response to be displayed in the event an expected return code is encountered.

Optional Field

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ReturnResponseUrl - The return response URL to be displayed in the event an expected return code is encountered.

Optional Field

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

AppsAndFeaturesEntries - AppsAndFeaturesEntries are used to match installed packages with manifests in configured sources.

Optional Field

This key represents the values reported by Windows Apps & Features. When a package is installed, entries are made into the Windows Registry.

DisplayName - DisplayName is what is displayed in the Control Panel for installed packages.

Optional Field

This key represents the package name as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

DisplayVersion - DisplayVersion is the version displayed in the Control Panel for installed packages.

Optional Field

This key represents the package version as displayed in Windows Apps & Features. It is used to help correlate installed packages with manifests in configured sources.

Note: When the PackageVersion and DisplayVersion are the same, the DisplayVersion should be omitted from the AppsAndFeaturesEntries

Publisher - Publisher is the value of the package publisher reported in the Windows registry.

Optional Field

This key represents the Publisher reported in the Windows registry. It is used to help correlate installed packages with manifests in configured sources.

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the product code for a package. It is used to help correlate installed packages with manifests in configured sources.

NOTE: This key is displayed twice for completeness. When AppsAndFeaturesEntries are specified, the ProductCode should be placed both within the installer and the AppsAndFeaturesEntries

UpgradeCode - UpgradeCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the upgrade code for a package. It is used to help correlate installed packages with manifests in configured sources.

InstallerType - Enumeration of supported installer types.

Optional Field

UnsupportedArguments - List of unsupported Windows Package Manager Client arguments for an installer.

Optional Field

DisplayInstallWarnings - Indicator for displaying a warning message prior to install or upgrade.

Optional Field

This key represents whether a warning message is displayed to the user prior to install or upgrade if the package is known to interfere with any running applications.

NOTE: The DisplayInstallWarnings behavior is not implemented in the Windows Package Manager 1.10 client.

InstallationMetadata - Details about the installation.

Optional Field

This key allows for additional metadata to be used for deeper installation detection.

DefaultInstallLocation - The default installed package location.

Optional Field

This key represents the default install location for the package.

Files - The list of installed files.

Optional Field

This key represents the files installed for the package.

RelativeFilePath - The relative path to the installed file.

Optional Field

This key represents the path to the installed file relative to the default install location.

FileSha256 - The optional Sha256 of the installed file.

Optional Field

This key represents the Sha256 hash of the installed file.

FileType - The optional installed file type.

Optional Field

This key represents the type of the installed file - launch, uninstall, or other. If not specified, the file is treated as other.

InvocationParameter - Optional parameter for invocable files.

Optional Field

This key represents the parameter to use for invocable files.

DisplayName - Optional display name for invocable files

Optional Field

This key represents the display name to use for invocable files.

DownloadCommandProhibited - Optional indicator for packages which cannot be downloaded for offline installation

Optional Field

When true, this flag will prohibit the manifest from being downloaded for offline installation with the winget download command

RepairBehavior - Optional repair method to use with 'winget repair`

Optional Field

ArchiveBinariesDependOnPath - Optional indication to add the install location directly to PATH. Only applies to an archive containing portable packages

Optional Field

text

**Authentication** - Authentication information for Entra Id secured private sources

Restricted Field

text

**AuthenticationType** - What type of authentication to use for Entra Id authentication

Restricted Field

This field controls the whether to use no authentication, Entra ID, or Entra ID for Azure Blob Storage.

text

**MicrosoftEntraIdAuthenticationInfo** - Information required for Entra Id authentication in private sources

Restricted Field

This field controls the authentication details used when downloading or installing packages from Entra Id secured private sources.

text

**Resource** - The resource to use for Microsoft Entra Id authentication

Restricted Field

This field controls the resource which will be used when using Entra Id for downloading or installing packages

text

**Scope** - The scope of Microsoft Entra Id authentication for the resource

Restricted Field

This field controls the scope which will be used when using Entra Id for downloading or installing packages

ManifestType - The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.10.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.10.0 Version (`doc/manifest/schema/1.10.0/version.md`)

Windows Package Manager

Manifest Schema v1.10.0 Version File

Version Manifest

yaml

PackageIdentifier:      # The package unique identifier
PackageVersion:         # The package version
DefaultLocale:          # The default package meta-data locale
ManifestType: version   # The manifest type
ManifestVersion: 1.10.0  # The manifest syntax version

Fields

PackageIdentifier - The package unique identifier

Required Field

This key is the unique identifier for a given package.

Windows Package Manager Community Repository

This value is generally in the form of Publisher.Package. It is case sensitive, and this value must match the folder structure under the partition directory.

PackageVersion - The package version

Required Field

DefaultLocale - The default package meta-data locale

Required Field

Windows Package Manager Community Repository

The validation pipelines use this value to ensure the corresponding locale file is present and conforms with the defaultLocale YAML specification.

ManifestType - The manifest type

Required Field

This key must have the value "version". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field
This key must have the value "1.10.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.12.0 DefaultLocale (`doc/manifest/schema/1.12.0/defaultLocale.md`)

Windows Package Manager

Manifest Schema v1.12.0 Default Locale File

Default Locale Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

The current best practice for the Windows Package Manager 1.12 client is to use the value reported in Windows Apps & Features when this version of the package is installed. In some cases, packages do not report a version resulting in an upgrade loop or other unwanted behavior.

PackageLocale - The package meta-data locale

Required Field

References:

Available languages for Windows
Default Input Profiles (Input Locales) in Windows

NOTE: This field is the key to determining which fields are required for the Microsoft community repository. The default locale specified in the version file must match with this value.

Publisher - The publisher name

Required Field

This key represents the name of the publisher for a given package. This field is intended to allow the full publisher's or ISV's name to be displayed as they wish.

NOTE: With the 1.12 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 and Windows 11 via Add / Remove Programs (ARP) and Windows Apps & Features respectively. The best practice is to ensure this matches the entry for the package when it has been installed. This should be the value of the Publisher subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PublisherUrl - The publisher home page

Optional Field

This key represents the web site for the publisher or ISV.

PublisherSupportUrl - The publisher support page

Optional Field

This key represents the customer support web site or specific web page provided by the publisher or ISV.

PrivacyUrl - The publisher privacy page or the package privacy page

Optional Field

This key represents the privacy web site or specific web page provided the publisher or ISV. If there is a privacy web site or specific web page for the package it is preferred over a generic privacy page for the publisher.

Author - The package author

Optional Field

This key represents the author of a package. In some cases, the author is an individual who develops and or maintains the package. In other cases this may be a URL pointing to the contributors web page for a package.

PackageName - The package name

Required Field

This key represents the name of the package. This field is intended to allow the full package name to be displayed as the publisher or ISV wishes.

NOTE: With the 1.12 release of the Windows Package Manager, this name affects how packages from a source are mapped to Apps installed in Windows 10 via Add / Remove Programs (ARP). The best practice is to ensure this matches the ARP entry for the package name when it has been installed. This should be the value of the DisplayName subkey for the package in the Windows registry. The impact is associated with winget upgrade and winget list.

PackageUrl - The package home page

Optional Field

This key represents the web site for the package.

License - The package license

Required Field

This key represents the license governing the use and or distribution for the product. This could be an open source license, or a commercial license. Please note that a copyright is not considered a license. If there is no available information on a product's license, "Proprietary" should be the value in this field.

LicenseUrl - The license page

Optional Field

This key represents the license web site or specific web page provided the publisher or ISV. If there is a license web site or specific web page for the package it is preferred over a generic license page for the publisher.

If this is a link to the license file for an open source project, it should be specific to the version for the package. Some open source projects change their license over time.

Copyright - The package copyright

Optional Field

This key represents the copyright for the package.

CopyrightUrl - The package copyright page

Optional Field

This key represents the copyright web site or specific web page provided the publisher or ISV. If there is a copyright web site or specific web page for the package it is preferred over a generic copyright page for the publisher.

If this is a link to the copyright file for an open source project, it should be specific to the version for the package. Some open source projects change their copyright over time.

ShortDescription - The short package description

Required Field

This key represents the description for a package. It is intended for use in winget show to help a user understand what the package is.

The value must be at least 3 characters long, and at most 256 characters long.

NOTE: This should be something descriptive about what the package does, and it should not simply state something like "<package name> installer" or "<package name> setup".

Description - The full package description

Optional Field

This key represents the full or long description for a package. It is not currently used in the Windows Package Manager.

NOTE: This was included for integration with the Microsoft Store source to provide the ability to display the full package description.

Moniker - The most common package term

Optional Field

This key represents the most common term users would search for when installing or upgrading a package. If only one package uses this moniker, then the install, list and upgrade command may match with this package.

NOTE: Moniker is the third property evaluated when searching for a matching package.

Tags - List of additional package search terms

Optional Field

This key represents other common term users would search for when looking for packages. Tags should be pertinent to what a user might search for when looking for a specific package.

A maximum of 16 tags can be added.

NOTE: The best practice is to present these terms in all lower case with hyphens rather than spaces.

Agreements - List of package agreements

Optional Field

This key holds any agreements a user must accept prior to download and subsequent install or upgrade.

Windows Package Manager Community Repository

Agreements are only allowed in the community repository when the manifest is maintained by a verified developer.

AgreementLabel - The label for a package agreement

Optional Field

This key represents the label for a package agreement.

Agreement - The text for a package agreement

Restricted Field

This key represents the text or body of a package agreement.

AgreementUrl - The URL for a package agreement

Optional Field

This key represents the URL for a package agreement.

Documentations - List of documentation

Optional Field

This key holds any documentation for providing software guides such as manuals and troubleshooting URLs.

DocumentLabel - The documentation label

Optional Field

This key represents the label for a documentation.

DocumentUrl - List of documentation

Optional Field

This key represents the URL for a documentation.

ReleaseNotes - The Release Notes for a package.

Optional Field

This key represents release notes for a package.

ReleaseNotesUrl - The Release Notes web page for a package.

Optional Field

This key represents release notes web page for a package.

PurchaseUrl - The Purchase URL for a package.

Optional Field

This key represents the purchase url for acquiring entitlement for a package.

InstallationNotes - The Installation Notes for a package.

Optional Field

This key represents the notes displayed to the user upon completion of a package installation.

ManifestType - The manifest type

Required Field

This key must have the value "defaultLocale". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.12.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Doc Manifest Schema 1.12.0 Installer (`doc/manifest/schema/1.12.0/installer.md`)

Windows Package Manager

Manifest Schema v1.12.0 Installer File

[!IMPORTANT]
The 1.12 manifest schema was released with the Windows Package Manager 1.12. Any fields marked Not implemented are not supported in the 1.12 client, but may be supported in newer versions of the client.

Installer Manifest

text

/* Detailed source-code truncated for AI context efficiency. */

Installer Minimal Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Installers:
  - Architecture: x64
    InstallerType: msix
    InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
    InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
ManifestType: installer
ManifestVersion: 1.12.0

Installer Complex Example

Path: manifests/m/Microsoft/WindowsTerminal/1.9.1942/Microsoft.WindowsTerminal.installer.yaml

yaml

PackageIdentifier: Microsoft.WindowsTerminal
PackageVersion: 1.9.1942.0
Platform:
- Windows.Desktop
MinimumOSVersion: 10.0.18362.0
InstallerType: msix
InstallModes:
- silent
PackageFamilyName: Microsoft.WindowsTerminal_8wekyb3d8bbwe
Installers:
- Architecture: x64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: arm64
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
- Architecture: x86
  InstallerUrl: https://github.com/microsoft/terminal/releases/download/v1.9.1942.0/Microsoft.WindowsTerminal_1.9.1942.0_8wekyb3d8bbwe.msixbundle
  InstallerSha256: 578D987D58B3CE5F6BF3316C6A5AECE8EB6B94DBCD1963413D81CB313D6C28D5
  SignatureSha256: 889A0BA756E74386F95A37F6A813C6D383DC21349A2D18E2B192D4E0E7F80659
ManifestType: installer
ManifestVersion: 1.12.0

Fields

PackageIdentifier - The package unique identifier

Required Field

PackageVersion - The package version

Required Field

Channel - The distribution channel

Optional Field

This key represents the distribution channel for a package. Examples may include "stable" or "beta".

Installers - Package installer

Required Field

The key represents an installer for a package.

Architecture - The installer target architecture

Required Field

Available architectures:

x86
x64
arm
arm64
neutral

InstallerLocale - Locale for package installer

Optional Field

Platform - The installer supported operating system

Optional Field

MinimumOSVersion - The installer minimum operating system version

Optional Field

This key represents the minimum version of the Windows operating system supported by the package.

InstallerType - Enumeration of supported installer types.

Required Field

InstallerType Font is supported as of Windows Package Manager 1.12. Font InstallerType includes the following types file extensions: .otf, .otc, .ttf, .ttc, and .fnt.

IMPORTANT: The Windows Package Manager 1.12 does not support loose executables with the .com file extension directly. Progressive Web Applications (PWAs) and fonts are also not supported.

NOTE: Using InstallerType or NestedInstallerType Font requires that the manifest root be "fonts" in order to pass submission validation. Font installer types are not permitted to be included in the "manifests" root. This is not a technical limitation in the Windows Package Manager; this is a submission policy requirement.

InstallerUrl - The installer Url

Required Field

This key represents the URL to download the installer.

InstallerSha256 - Sha256 is required. Sha256 of the installer

Required Field

SignatureSha256 - SignatureSha256 is recommended for appx or msix. It is the sha256 of signature file inside appx or msix. Could be used during streaming install if applicable

Optional Field

This key represents the signature file (AppxSignature.p7x) inside an MSIX installer. It is used to provide streaming install for MSIX packages.

NestedInstallerType - NestedInstallerType is required when InstallerType is an archive type such as '.zip'

Required Field

This key represents the installer type of the file within the archive which will be used as the installer.

NestedInstallerType Font is supported as of Windows Package Manager 1.12.

NestedInstallerFiles - NestedInstallerFiles is required when InstallerType is an archive type such as '.zip'

Required Field

This key is a list of all the installers to be executed within an archive.

IMPORTANT: This field can only contain one nested installer file unless the NestedInstallerType is 'portable'

RelativeFilePath - RelativeFilePath is required within NestedInstallerFiles

Required Field

The relative path to the installer file contained within the archive.

PortableCommandAlias - The command alias to be used for calling the package

Optional Field

The alias which is added to the PATH for calling the package from the command line.

IMPORTANT: This field is only valid when NestedInstallerType is 'portable'

Scope - Scope indicates if the installer is per user or per machine

Optional Field

InstallModes - List of supported installer modes

Optional Field

InstallerSwitches - Switches passed to installers

Optional Field

This key represents the set of switches passed to installers.

Windows Package Manager Community Repository

Silent - Silent is the value that should be passed to the installer when user chooses a silent or quiet install

Optional Field

This key represents switches passed to the installer to provide a silent install experience. These would be used when the command winget install --silent is executed.

SilentWithProgress - SilentWithProgress is the value that should be passed to the installer when user chooses a non-interactive install

Optional Field

Interactive - Interactive is the value that should be passed to the installer when user chooses an interactive install

Optional Field

InstallLocation - InstallLocation is the value passed to the installer for custom install location.

Optional Field

Log - Log is the value passed to the installer for custom log file path.

Optional Field

Upgrade - Upgrade is the value that should be passed to the installer when user chooses an upgrade.

Optional Field

This key represents the switches to be passed to the installer during an upgrade. This will happen only if the upgrade behavior is "install".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Custom - Custom switches will be passed directly to the installer by the Windows Package Manager.

Optional Field

This key represents any switches the Windows Package Manager will pass to the installer in addition to "Silent", "SilentWithProgress", and "Interactive".

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

Repair - Repair is the value that should be passed to the installer when a user chooses to repair an existing installation

Optional Field

NOTE: If a user applies override switches via command line via the Windows Package Manager, none of the switches from the manifest will be passed to the installer.

UpgradeBehavior - The upgrade method

Optional Field

Commands - List of commands or aliases to run the package

Optional Field

This key represents any commands or aliases used to execute the package after it has been installed.

Protocols - List of protocols the package provides a handler for

Optional Field

FileExtensions - List of file extensions the package could support

Optional Field

Dependencies - List of dependencies needed to install or execute the package

Optional Field

This key represents any dependencies required to install or run the package.

ExternalDependencies - List of external package dependencies

Optional Field

This key represents any external dependencies required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to external dependencies.

PackageDependencies - List of package dependencies from current source

Optional Field

This key represents any packages from the same source required to install or run the package.

IMPORTANT: Dependencies are referenced by their package identifier and must come from the same source.

WindowsFeatures - List of Windows feature dependencies

Optional Field

This key represents any Windows features required to install or run the package.

WindowsLibraries - List of Windows library dependencies

Optional Field

This key represents any Windows libraries required to install or run the package.

IMPORTANT: The Windows Package Manager does not support any behavior related to Windows Libraries.

PackageFamilyName - PackageFamilyName for appx or msix installer. Could be used for correlation of packages across sources

Optional Field

Capabilities - List of appx or msix installer capabilities

Restricted Field

This key represents the capabilities provided by an MSIX package. More information is available for App capability declarations

RestrictedCapabilities - List of appx or msix installer restricted capabilities

Restricted Field

This key represents the restricted capabilities provided by an MSIX package. More information is available for App capability declarations

InstallerAbortsTerminal - Indicator for installers that abort the terminal.

Optional Field

This key represents the behavior associated with installers that abort the terminal. This most often occurs when a user is performing an upgrade of the running terminal.

NOTE: Windows Terminal no longer causes this to occur as the MSIX install behavior from the Windows Package Manager is deferred registration.

InstallLocationRequired - Indicator for packages requiring an install location to be specified.

Optional Field

This key represents the requirement to have an install location specified. These installers are known to deploy files to the location the installer is executed in.

RequireExplicitUpgrade - Indicator for packages that upgrade themselves.

Optional Field

This key identifies packages that upgrade themselves. By default, they are excluded from winget upgrade --all.

ElevationRequirement - Indicator for elevation behavior when installing or upgrading packages.

Optional Field

This key describes how the installer interacts with elevation (administrator privileges). It tells WinGet whether to request elevation on the user's behalf, whether the installer handles elevation itself, or whether elevation must be avoided entirely.

elevationRequired — The installer always requires administrator privileges to complete (e.g., it writes to Program Files, modifies system registry keys, or installs a Windows service). If WinGet is running in a non-elevated context, it will launch the installer elevated via a UAC prompt.
elevatesSelf — The installer contains its own logic to determine whether elevation is needed and will request it when necessary. For example, the installer may check whether the current user is a member of the local Administrators group and automatically switch between a per-user and machine-wide installation. WinGet will not elevate the installer itself but will warn the user that a UAC prompt may appear.
elevationProhibited — The installer must not be run from an elevated (administrator) context. If WinGet is running elevated, the installation will be blocked.

Choosing between elevationRequired and elevatesSelf: Use elevationRequired when the installer unconditionally needs administrator privileges due to what it installs (protected file locations, HKLM registry, system services). Use elevatesSelf when the installer has built-in logic that conditionally decides whether elevation is needed based on runtime checks.

UnsupportedOSArchitectures - List of unsupported architectures for a package.

Optional Field

This key represents any architectures a package is known not to be compatible with. Generally, this is associated with emulation modes.

Markets - List of supported markets for a package.

Restricted Field

This key represents any markets a package may be installed in.

IMPORTANT: If a market is listed in both this key and the ExcludedMarkets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

ExcludedMarkets - List of unsupported markets for a package.

Restricted Field

This key represents any markets a package may not be installed in.

IMPORTANT: If a market is listed in both this key and the Markets key, the market will be excluded. Both keys are present to reduce the need to list the larger set of markets.

InstallerSuccessCodes - List of additional non-zero installer success exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a success condition other than zero.

ExpectedReturnCodes - List of additional non-zero installer exit codes other than known default values by the Windows Package Manager.

Optional Field

This key represents any status codes returned by the installer representing a condition other than zero.

InstallerReturnCode - The non-zero installer exit code other than known default values by the Windows Package Manager.

Optional Field

ReturnResponse - The return response to be displayed in the event an expected return code is encountered.

Optional Field

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ReturnResponseUrl - The return response URL to be displayed in the event an expected return code is encountered.

Optional Field

NOTE: An enumerated list of values in the JSON schema must be specified for consistency of user experience.

ProductCode - ProductCode is used for correlation of packages with manifests is configured sources.

Optional Field

AppsAndFeaturesEntries - AppsAndFeaturesEntries are used to match installed packages with manifests in configured sources.

Optional Field

This key represents the values reported by Windows Apps & Features. When a package is installed, entries are made into the Windows Registry.

DisplayName - DisplayName is what is displayed in the Control Panel for installed packages.

Optional Field

DisplayVersion - DisplayVersion is the version displayed in the Control Panel for installed packages.

Optional Field

Note: When the PackageVersion and DisplayVersion are the same, the DisplayVersion should be omitted from the AppsAndFeaturesEntries

Publisher - Publisher is the value of the package publisher reported in the Windows registry.

Optional Field

ProductCode - ProductCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the product code for a package. It is used to help correlate installed packages with manifests in configured sources.

NOTE: This key is displayed twice for completeness. When AppsAndFeaturesEntries are specified, the ProductCode should be placed both within the installer and the AppsAndFeaturesEntries

UpgradeCode - UpgradeCode is used for correlation of packages with manifests in configured sources.

Optional Field

This key represents the upgrade code for a package. It is used to help correlate installed packages with manifests in configured sources.

InstallerType - Enumeration of supported installer types.

Optional Field

UnsupportedArguments - List of unsupported Windows Package Manager Client arguments for an installer.

Optional Field

DisplayInstallWarnings - Indicator for displaying a warning message prior to install or upgrade.

Optional Field

This key represents whether a warning message is displayed to the user prior to install or upgrade if the package is known to interfere with any running applications.

NOTE: The DisplayInstallWarnings behavior is not implemented in the Windows Package Manager 1.12 client.

ReleaseDate - The Release Date for a package.

Optional Field

This key represents the release date for a package, in RFC 3339 / ISO 8601 format, i.e. "YYYY-MM-DD".

InstallationMetadata - Details about the installation.

Optional Field

This key allows for additional metadata to be used for deeper installation detection.

DefaultInstallLocation - The default installed package location.

Optional Field

This key represents the default install location for the package.

Files - The list of installed files.

Optional Field

This key represents the files installed for the package.

RelativeFilePath - The relative path to the installed file.

Optional Field

This key represents the path to the installed file relative to the default install location.

FileSha256 - The optional Sha256 of the installed file.

Optional Field

This key represents the Sha256 hash of the installed file.

FileType - The optional installed file type.

Optional Field

This key represents the type of the installed file - launch, uninstall, or other. If not specified, the file is treated as other.

InvocationParameter - Optional parameter for invocable files.

Optional Field

This key represents the parameter to use for invocable files.

DisplayName - Optional display name for invocable files

Optional Field

This key represents the display name to use for invocable files.

DownloadCommandProhibited - Optional indicator for packages which cannot be downloaded for offline installation

Optional Field

When true, this flag will prohibit the manifest from being downloaded for offline installation with the winget download command

RepairBehavior - Optional repair method to use with 'winget repair`

Optional Field

ArchiveBinariesDependOnPath - Optional indication to add the install location directly to PATH. Only applies to an archive containing portable packages

Optional Field

text

**Authentication** - Authentication information for Entra Id secured private sources

Restricted Field

text

**AuthenticationType** - What type of authentication to use for Entra Id authentication

Restricted Field

This field controls the whether to use no authentication, Entra ID, or Entra ID for Azure Blob Storage.

text

**MicrosoftEntraIdAuthenticationInfo** - Information required for Entra Id authentication in private sources

Restricted Field

This field controls the authentication details used when downloading or installing packages from Entra Id secured private sources.

text

**Resource** - The resource to use for Microsoft Entra Id authentication

Restricted Field

This field controls the resource which will be used when using Entra Id for downloading or installing packages

text

**Scope** - The scope of Microsoft Entra Id authentication for the resource

Restricted Field

This field controls the scope which will be used when using Entra Id for downloading or installing packages

ManifestType - The manifest type

Required Field

This key must have the value "installer". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

ManifestVersion - The manifest syntax version

Required Field

This key must have the value "1.12.0". The Microsoft community package repository validation pipelines also use this value to determine appropriate validation rules when evaluating this file.

Technical Documentation: microsoft/winget-pkgs

Overview (README.md) Copy Section

Windows Package Manager Community Repository

Documentation

Contributing

Doc README (`doc/README.md`) Copy Section

Documentation Overview

Authoring a Manifest Copy Chapter

Testing a Manifest Copy Chapter

Locally Copy Section

In Windows Sandbox Copy Section

Submitting a Manifest Copy Chapter

Submit your PR Copy Chapter

Validation Process Copy Section

Community Repository Policies

Respond to PR feedback Copy Section

Doc Manifest README (`doc/manifest/README.md`) Copy Section

WinGet Manifests

Manifest Schema Versions Copy Chapter

Doc Private README (`doc/private/README.md`) Copy Section

Third-party repositories

Third-party repository implementations Copy Chapter

Third-party repositories Copy Chapter

Doc Manifest Schema 1.0.0 README (`doc/manifest/schema/1.0.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.0 Copy Chapter

Doc Manifest Schema 1.1.0 README (`doc/manifest/schema/1.1.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.1 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Doc Manifest Schema 1.10.0 README (`doc/manifest/schema/1.10.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.10 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Summary of Changes from 1.9.0 Copy Chapter

[Version](version.md) Copy Section

[Default Locale](defaultLocale.md) Copy Section

[Installer](installer.md) Copy Section

[Locale](locale.md) Copy Section

Doc Manifest Schema 1.12.0 README (`doc/manifest/schema/1.12.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.12 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Summary of Changes from 1.10.0 Copy Chapter

[Version](version.md) Copy Section

[Default Locale](defaultLocale.md) Copy Section

[Installer](installer.md) Copy Section

[Locale](locale.md) Copy Section

Doc Manifest Schema 1.2.0 README (`doc/manifest/schema/1.2.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.2 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Doc Manifest Schema 1.28.0 README (`doc/manifest/schema/1.28.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.28 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Summary of Changes from 1.12.0 Copy Chapter

[Version](version.md) Copy Section

[Default Locale](defaultLocale.md) Copy Section

[Installer](installer.md) Copy Section

[Locale](locale.md) Copy Section

Doc Manifest Schema 1.4.0 README (`doc/manifest/schema/1.4.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.4 Copy Chapter

YAML file name and folder structure Copy Chapter

YAML Syntax Copy Chapter

Best Practices Copy Chapter

Doc Manifest Schema 1.5.0 README (`doc/manifest/schema/1.5.0/README.md`) Copy Section

Windows Package Manager

Manifest Schema 1.5 Copy Chapter

Overview (README.md)

Doc README (`doc/README.md`)

Authoring a Manifest

Testing a Manifest

Locally

In Windows Sandbox

Submitting a Manifest

Submit your PR

Validation Process

Respond to PR feedback

Doc Manifest README (`doc/manifest/README.md`)

Manifest Schema Versions

Doc Private README (`doc/private/README.md`)

Third-party repository implementations

Third-party repositories

Doc Manifest Schema 1.0.0 README (`doc/manifest/schema/1.0.0/README.md`)

Manifest Schema 1.0

Doc Manifest Schema 1.1.0 README (`doc/manifest/schema/1.1.0/README.md`)

Manifest Schema 1.1

YAML file name and folder structure

YAML Syntax

Best Practices

Doc Manifest Schema 1.10.0 README (`doc/manifest/schema/1.10.0/README.md`)

Manifest Schema 1.10

YAML file name and folder structure

YAML Syntax

Best Practices

Summary of Changes from 1.9.0

[Version](version.md)

[Default Locale](defaultLocale.md)

[Installer](installer.md)

[Locale](locale.md)

Doc Manifest Schema 1.12.0 README (`doc/manifest/schema/1.12.0/README.md`)

Manifest Schema 1.12

YAML file name and folder structure

YAML Syntax

Best Practices

Summary of Changes from 1.10.0

[Version](version.md)

[Default Locale](defaultLocale.md)

[Installer](installer.md)

[Locale](locale.md)

Doc Manifest Schema 1.2.0 README (`doc/manifest/schema/1.2.0/README.md`)

Manifest Schema 1.2

YAML file name and folder structure

YAML Syntax

Best Practices

Doc Manifest Schema 1.28.0 README (`doc/manifest/schema/1.28.0/README.md`)

Manifest Schema 1.28

YAML file name and folder structure

YAML Syntax

Best Practices

Summary of Changes from 1.12.0

[Version](version.md)

[Default Locale](defaultLocale.md)

[Installer](installer.md)

[Locale](locale.md)

Doc Manifest Schema 1.4.0 README (`doc/manifest/schema/1.4.0/README.md`)

Manifest Schema 1.4

YAML file name and folder structure

YAML Syntax

Best Practices

Doc Manifest Schema 1.5.0 README (`doc/manifest/schema/1.5.0/README.md`)

Manifest Schema 1.5

YAML file name and folder structure

YAML Syntax

Best Practices

Doc Manifest Schema 1.6.0 README (`doc/manifest/schema/1.6.0/README.md`)

Manifest Schema 1.6

YAML file name and folder structure

YAML Syntax

Best Practices

Doc Manifest Schema 1.7.0 README (`doc/manifest/schema/1.7.0/README.md`)

Manifest Schema 1.7

YAML file name and folder structure

YAML Syntax

Best Practices

Summary of Changes from 1.6.0

[Version](version.md)

[Default Locale](defaultLocale.md)