winget-create, generating and updating Windows Package Manager manifests

What a winget manifest actually is

The Windows Package Manager, or winget, installs applications on Windows from manifest files. Those manifests live in a community repository, winget-pkgs, and each one describes where to get an installer, what its hash is, and how the package presents itself to the user. The manifest is the contract between a publisher and every winget user.

Writing one by hand is unpleasant work. It is a YAML document with a package identifier, a version, a set of installer URLs scoped by architecture and installer type, SHA-256 hashes, license and release date fields, and a manifest version that has to be bumped as the schema changes. A publisher who updates their application has to produce a new version string, new URLs, new hashes and a new manifest version, and a mismatch in any one of them means the package fails to install.

WingetCreate, which the project documentation also calls WingetCreate, is the tool Microsoft built to remove that friction. It is described as an open source tool designed to help developers create, update and submit manifest files to the Windows Package Manager repository, and it is intended for developers who want to submit their applications for use with the Windows Package Manager.

The audience is a software team that publishes a Windows application and wants it installable with `winget install`. The scope is narrow and deliberate. This is not a general packaging tool that produces installers; it produces the metadata that points at installers you already host.

The repository is under the microsoft organisation, written in C#, and the licence is MIT with a LICENSE file, a NOTICE.txt and a PRIVACY.md at the top level.

The command set, from New to Update-Locale

The command list in the project documentation is the clearest description of the tool's scope, and it is worth reading as a workflow.

`New` creates a new manifest from scratch, and `Update` updates an existing manifest. The two locale commands, `New-Locale` and `Update-Locale`, create or update a locale for an existing manifest, which is how a package with translations gets a new language added without rewriting the whole document. `Submit` submits an existing pull request, and `Show` displays existing manifests.

Then there is the tooling around it. `Token` manages cached GitHub personal access tokens, and `Cache` manages the downloaded installers that are stored in cache. `Settings` edits the settings file configurations, `Info` displays information about the client, `Dsc` exposes DSC v3 resource commands for Desired State Configuration, and `-?` displays command line help.

Two of these deserve a note. `Token` exists because submission needs GitHub credentials, and caching the token on disk means you are not typing it into every command. `Cache` exists because the tool downloads installers to compute their hashes, and a large package can be a substantial download, so the cache saves repeating it.

The `Dsc` command is the one that sits oddly in the list. DSC is a Windows configuration mechanism, and the connection to manifest generation is not obvious from the documentation, so the doc/dsc.md page is where you would look. Its presence suggests the tool is used in some configuration-management scenarios beyond a developer sitting in front of a prompt.

Each command has its own page under doc/, and the documentation links to them individually rather than describing them in prose.

Installing the tool four ways

The getting started section says WingetCreate can be acquired a number of ways, and it lists four.

The first is downloading the MSIX from the winget-create releases page, clicking it in the browser, and then clicking open once it has downloaded. The second is installing it with the Windows Package Manager itself, which is a nice bit of recursion.

winget install wingetcreate

The third is Scoop.

scoop install wingetcreate

And the fourth is Chocolatey.

choco install wingetcreate

That is a lot of ways to install a developer tool, and it reflects the fact that Windows developers have three package managers in common use. If you already use one of them, WingetCreate installs in a single command.

There is also the standalone executable, which is a separate distribution channel that matters for CI. The latest version of the standalone exe is published at https://aka.ms/wingetcreate/latest and the latest preview at https://aka.ms/wingetcreate/preview, and both require the .NET Runtime 6.0 to be installed on the build machine. The documentation gives the Azure Pipelines task to install it.

      - task: UseDotNet@2
        displayName: 'Install .NET Runtime'
        inputs:
          packageType: sdk
          version: '6.x'
          installationPath: '$(ProgramFiles)\dotnet'

And the PowerShell alternative for machines where the task is not available.

    Invoke-WebRequest https://dot.net/v1/dotnet-install.ps1 -OutFile dotnet-install.ps1
    .\dotnet-install.ps1 -Runtime dotnet -Architecture x64 -Version 6.0.13 -InstallDir $env:ProgramFiles\dotnet

There is a third distribution, the msixbundle, and it comes with a condition worth knowing. Windows Server 2022 now supports App Execution Aliases, which means the alias `wingetcreate` can be used to run the tool after installing the msixbundle.

Updating a manifest from a release pipeline

This is the part of the tool that has the most value for a shipping product, and the documentation is clear that the intended use is inside CI/CD.

You can use WingetCreate to update your existing app manifest as part of your CI/CD pipeline, and the documentation points at the final task in the repository's own release Azure pipeline as a reference implementation. It also lists the projects that have adopted the approach: Copilot CLI, Edit, Oh-My-Posh, PowerToys, Terminal and WinGet Studio, each with a linked workflow file. That list is worth a look for a developer deciding how to structure the step, because six different teams have solved the same problem in six slightly different ways.

The standalone exe path in a pipeline is two steps. Download the executable, then run it with the package id and the values you want to apply.

    Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
    .\wingetcreate.exe update <packageId> -u $(packageUrls) -v $(manifestVersion) -t $(GITHUB_PAT)

The flags are readable: the package identifier, the URLs, the manifest version and the token.

Two security points are made in the documentation and both matter. You need a GitHub personal access token if you want to submit your updated manifest, and it is not recommended to hardcode your PAT in your script because that poses a security threat. Instead you should store it as a secret pipeline variable, or a repository secret in the case of GitHub Actions.

There is also a runtime dependency that is easy to miss. The documentation states that you must make sure the build machine has the Microsoft Visual C++ Redistributable for Visual Studio already installed, and that without it the standalone WingetCreate exe will fail to execute and likely show a DllNotFoundException error. The msixbundle route has the same class of dependency, on the C++ Runtime Desktop framework package.

The build machine needs the redistributable, the .NET runtime and the tool itself. Miss any one and the pipeline fails at run time rather than at configuration time.

The repository layout and what it costs to keep a package alive

The top-level tree shows a project that has grown beyond a single command line program.

There is `src/` for the source, `doc/` for the per-command documentation, `pipelines/` for the Azure pipeline definitions, `Tools/` for build tooling, and `Localization/` for the localized resources that a Microsoft product needs across a dozen languages. The build configuration is a modern .NET one: `Directory.Packages.props` for central package version management, `NuGet.config` and `NuGet.Internal.config` for feeds, and a `global.json` pinning the SDK. There is a `.vsconfig` for the C++ components, an `.editorconfig`, an `AGENTS.md`, a `CODEOWNERS` file, and a `SUPPORT.md` alongside the usual `CONTRIBUTING.md` and `CODE_OF_CONDUCT.md`.

The build status badge points at an Azure DevOps pipeline rather than GitHub Actions, and the release pipelines live under `pipelines/`. The `global.json` and `Directory.Packages.props` combination means the SDK version and every NuGet dependency version are pinned in the repository, which is what you want in a tool whose output has to be reproducible across machines.

The cost side of the equation is the part that is easy to underestimate. A winget manifest is not a one-time submission. Every release of your application needs a new manifest version, new installer URLs and new hashes, and the old version stays in the repository so that users who pinned it can still install it. A tool that automates the update is saving you the mechanical part of that work, but the decision of when to publish a new manifest is still yours.

The release history shows the tool itself is actively moving. The recorded releases are v1.12.13.0 from 2026-07-23, v1.12.8.0 from 2026-03-14 and v1.10.3.0 from 2025-07-25, and the last push to the repository was on 2026-10-19. The version numbers are a Microsoft four-part scheme, and the gaps between them reflect a tool that is still gaining commands.

Editorial conclusion

WingetCreate suits a team that ships a Windows application and wants it installable through winget, and it suits that team most if version bumps are wired into the release pipeline rather than done by hand. It does not suit a developer with one application and no intention of maintaining it, because a manifest that is not updated is a manifest that points at an installer your users can no longer download. Verify first that the URLs you put in the manifest are still live, that the installer hash is regenerated on every release, and that the token you use for submissions is stored as a pipeline secret rather than committed to the workflow file.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/winget-create on GitHub
4. README
5. Releases