microsoft/winget-create

The Windows Package Manager Manifest Creator command-line tool (aka wingetcreate)

Welcome to the Windows Package Manager Manifest Creator repository.

This repository contains the source code for the Windows Package Manager Manifest Creator. The Windows Package Manager Manifest Creator is designed to help generate or update manifest files for the Community repo.

Overview

Windows Package Manager Manifest Creator is an Open Source tool designed to help developers create, update, and submit manifest files to the Windows Package Manager repository.

Developers will use this tool to submit their applications for use with the Windows Package Manager.

Getting Started

For your convenience, WingetCreate can be acquired a number of ways.

Install from the github repo

The Windows Package Manager Manifest Creator is available for download from the winget-create repository. To install the package, simply click the the MSIX file in your browser. Once it has downloaded, click open.

Install with Windows Package Manager

winget install wingetcreate

Install with Scoop

scoop install wingetcreate

Install with Chocolatey

choco install wingetcreate

Build status

Using Windows Package Manager Manifest Creator

WingetCreate has the following commands:

Command	Description
New	Command for creating a new manifest from scratch
Update	Command for updating an existing manifest
New-Locale	Command for creating a new locale for an existing manifest
Update-Locale	Command for updating a locale for an existing manifest
Submit	Command for submitting an existing PR
Show	Command for displaying existing manifests
Token	Command for managing cached GitHub personal access tokens
Settings	Command for editing the settings file configurations
Cache	Command for managing downloaded installers stored in cache
Info	Displays information about the client
-?	Displays command line help

Click on the individual commands to learn more.

Using Windows Package Manager Manifest Creator in a CI/CD pipeline

You can use WingetCreate to update your existing app manifest as part of your CI/CD pipeline. For reference, see the final task in this repo's release Azure pipeline. If you are utilizing GitHub Actions as your CI pipeline, you can refer to the following repositories that have implemented WingetCreate within their release pipelines:

• DevHome
• Oh-My-Posh
• PowerToys
• Terminal

You can also check out this episode of Open at Microsoft where we cover the same topic.

Using the standalone exe:

The latest version of the standalone exe can be found at https://aka.ms/wingetcreate/latest, and the latest preview version can be found at https://aka.ms/wingetcreate/preview, both of these require .NET Runtime 6.0 to be installed on the build machine. To install this on your build machine in your pipeline, you can include the following dotnet task:

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

Or you can utilize a PowerShell task and run the following script.

    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

Important

Make sure your build machine has the Microsoft Visual C++ Redistributable for Visual Studio already installed. Without this, the standalone WingetCreate exe will fail to execute and likely show a "DllNotFoundException" error.

To execute the standalone exe, add another PowerShell task to download and run the ./wingetcreate.exe to update your existing manifest. You will need a GitHub personal access token if you would like to submit your updated manifest. It is not recommended to hardcode your PAT in your script as this poses as a security threat. You should instead store your PAT as a secret pipeline variable or a repository secret in case of GitHub Actions.

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

Using the msixbundle:

Windows Server 2022 now supports App Execution Aliases, which means the alias wingetcreate can be used to run the tool after installing the msixbundle. The latest version of the msixbundle can be found at https://aka.ms/wingetcreate/latest/msixbundle. Similar to the standalone exe steps, download the msixbundle, add the package, and run wingetcreate to update your manifest.

Important

Winget-Create has a dependency on the C++ Runtime Desktop framework package. Be sure to also download and install this package prior to installing wingetcreate as shown in the steps below.

- powershell: |
        # Download and install C++ Runtime framework package.
        iwr https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx -OutFile $(vcLibsBundleFile)
        Add-AppxPackage $(vcLibsBundleFile)

        # Download Winget-Create msixbundle, install, and execute update.
        iwr https://aka.ms/wingetcreate/latest/msixbundle -OutFile $(appxBundleFile)
        Add-AppxPackage $(appxBundleFile)
        wingetcreate update Microsoft.WingetCreate -u $(packageUrl) -v $(manifestVersion) -t $(GITHUB_PAT) --submit

The CLI also supports creating or updating manifests with multiple installer URLs. You can either create new manifests with multiple installer nodes using the New Command or update existing manifests with multiple installer URLs using the Update Command.

GitHub Personal Access Token (classic) Permissions

When creating your own GitHub Personal Access Token (PAT) to be used with WingetCreate, make sure the following permissions are selected.

• Select the public_repo scope to allow access to public repositories

• (Optional) Select the delete_repo scope permission if you want WingetCreate to automatically delete the forked repo that it created if the PR submission fails.

Building the client

Prerequisites

You can install the prerequisites in one of two ways:

Using the configuration file

1. Clone the repository
2. Configure your system
   • Please use the configuration file. This can be applied by either:
     • Dev Home's machine configuration tool
     • WinGet configuration. If you have WinGet version v1.6.2631 or later, run winget configure .configurations/configuration.dsc.yaml in an elevated shell from the project root so relative paths resolve correctly
   • Alternatively, if you already are running the minimum OS version, have Visual Studio installed, and have developer mode enabled, you may configure your Visual Studio directly via the .vsconfig file. To do this:
     • Open the Visual Studio Installer, select “More” on your product card and then "Import configuration"
     • Specify the .vsconfig file at the root of the repo and select “Review Details”

Manual set up

• Windows 10 1709 (16299) or later
• Developer mode enabled (optional)
• Visual Studio 2022
  • Or use winget to install it ;) (although you may need to adjust the workloads via Tools -> Get Tools and Features...)
• Git Large File Storage (LFS)
• The following workloads:
  • .NET Desktop Development
  • Universal Windows Platform Development
• Windows 11 SDK (10.0.22000.0) (Tools -> Get Tools and Features -> Individual Components)

Building

Open winget-create\src\WingetCreateCLI.sln in Visual Studio and build. We currently only build using the solution; command line methods of building a VS solution should work as well.

Testing the client

Running Unit and E2E Tests

Running unit and E2E tests are a great way to ensure that functionality is preserved across major changes. You can run these tests in Visual Studio Test Explorer.

Testing Prerequisites

• Fork the winget-pkgs-submission-test repository

• Fill out the test parameters in the WingetCreateTests/Test.runsettings file

  • WingetPkgsTestRepoOwner: The repository owner of the winget-pkgs-submission-test repo. (Repo owner must be forked from main "winget-pkgs-submission-test" repo)
  • WingetPkgsTestRepo: The winget-pkgs test repository. (winget-pkgs-submission-test)
  • GitHubApiKey: GitHub personal access token for testing.
    • Instructions on how to generate your own GitHubApiKey.
    • Direct link to GitHub Personal Access Tokens page.
  • GitHubAppPrivateKey: Leave blank, this is only used by the build server.

• Set the solution wide runsettings file for the tests

  • Go to Test menu > Configure Run Settings -> Select Solution Wide runsettings File -> Choose your configured runsettings file

Caution

You should treat your access token like a password. To avoid exposing your PAT, be sure to reset changes to the WingetCreateTests/Test.runsettings file before committing your changes. You can also use the command git update-index --skip-worktree src/WingetCreateTests/WingetCreateTests/Test.runsettings command to untrack changes to the file and prevent it from being committed.

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 actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com. More information is available in our CONTRIBUTING.md file.

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). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information, please refer to the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Data/Telemetry

The wingetcreate.exe client is instrumented to collect usage and diagnostic (error) data and sends it to Microsoft to help improve the product.

If you build the client yourself the instrumentation will not be enabled and no data will be sent to Microsoft.

The wingetcreate.exe client respects machine wide privacy settings and users can opt-out on their device, as documented in the Microsoft Windows privacy statement here.

In short to opt-out, do one of the following:

Windows 11: Go to Start, then select Settings > Privacy & security > Diagnostics & feedback > Diagnostic data and unselect Send optional diagnostic data.

Windows 10: Go to Start, then select Settings > Privacy > Diagnostics & feedback, and select Required diagnostic data.

You can also opt-out of telemetry by configuring the settings.json file and setting the telemetry.disabled field to true. More information can be found in our Settings Command documentation

See the privacy statement for more details.

Known Issues

Certain functionalities of wingetcreate, particularly input prompting, may not be fully supported on certain shells such as PowerShell ISE. The supported shells for the prompting package utilized by wingetcreate are specified here

winget-create's Issues

Testing the bot

The bot should mark this issue as "Needs Triage"

`wingetcreate update --id` should prompt for the information.

Description of the new feature/enhancement

wingetcreate update --id does... nothing? if the manifest does not use a dynamic url. if -v -u -s is not inputted it should prompt for the information.

#19

Proposed technical implementation details (optional)

`wingetcreate update` does not prompt to update any of the information

Description of the new feature/enhancement

wingetcreate update does not prompt to update any of the information

#19

Proposed technical implementation details (optional)

Check at startup to determine if there's a newer release and prompt user to update

Description of the new feature/enhancement

We should check GitHub at startup to see if there's a newer release available than what the user is currently running, and if so, prompt the user to update (maybe provide the winget command they'd run to update for ease)

(Potentially fail execution if the newest release is a major version update, to prevent user creating broken manifests?)

Proposed technical implementation details (optional)

Call GitHub releases API at startup, and check against assembly version, acting with above logic

Missing DLL when using in CI

Brief description of your issue

I'm trying to embed wingetcreate in my CI workflow by downloading the tool and using the sumbit command to auto-create a PR. When doing so, this fails due to a missing DLL.

System.DllNotFoundException: Unable to load DLL 'WinGetUtil.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
   at Microsoft.WingetCreateCore.Common.WinGetUtil.WinGetValidateManifest(String manifestPath, Boolean& succeeded, String& failureMessage)
   at Microsoft.WingetCreateCore.Common.WinGetUtil.ValidateManifest(String manifestPath)
   at Microsoft.WingetCreateCLI.Commands.BaseCommand.ValidateManifest(String manifestPath)
   at Microsoft.WingetCreateCLI.Commands.SubmitCommand.SubmitManifest()
   at Microsoft.WingetCreateCLI.Commands.SubmitCommand.Execute()
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)

Steps to reproduce

# Get the latest wingetcreate exe
Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
# Create the PR
wingetcreate.exe submit --token $Token $Version

Expected behavior

Should execute the submit command without error. This should work without any other dependencies.

Actual behavior

Fails due to missing DLL.

Environment

OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19042 N/A Build 19042
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
BIOS Version: Parallels Software International Inc. 16.5.0 (49183), 4/2/2021

When trying to get the version number of wingetcreate it fails with the following as well:

.\wingetcreate.exe -?
                                                                                                     
A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [Y:\oh-my-posh\packages\winget\].
If this is a framework-dependent application, install the runtime in the global location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\InstallLocation].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win10-x64&apphost_version=5.0.5

Search for duplicates

Description of the new feature/enhancement

There should be a way to search for duplicates when executing wingetcreate new. This may mean a dependency on the Windows Package Manager. There is also a feature in the winget-pkgs repository to evaluate SHA256 hashes and provide a warning.

Proposed technical implementation details (optional)

Once the installer has been downloaded and parsed, several different search parameters are available like the package name the installer URL and the SHA256 hash. This may also justify other features on the Windows Package Manager client to support additional search parameters for different values.

Add Progress bar for "Downloading and parsing:"

Description of the new feature/enhancement

I'd like to have a progress bar like the one in winget when "Downloading and parsing:" the installer.

Proposed technical implementation details (optional)

Build a PowerShell cmdlet for wingetcreate

Description of the new feature/enhancement

PowerShell ! ! !

microsoft/winget-cli#221

Proposed technical implementation details (optional)

Unhandled exception on submitting pull request for manifest - part of winget-create new operation

As part of testing winget-create new, I'm trying to submit the manifest to the WIndows Package Manager repository and encountering the following error:

Submitting pull request for manifest...

Unhandled exception. System.FormatException: Input string was not in a correct format.
at System.Text.ValueStringBuilder.ThrowFormatError()
at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.Format(String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
at Microsoft.WingetCreateCLI.Program.Main(String[] args)
at Microsoft.WingetCreateCLI.Program.

(String[] args)

wingetcreate storing installers in %temp% folder

Description

When creating new or updating existing manifest, wingetcreate is given a download link to the installer so that it can download the application and generate sha256. I've noticed that wingetcreate stores the installer in %temp% folder after generating sha256. I like this behavior because if I had to do some testing with the installer or get some metadata from it, I would not have to download the installer again. But this could cause storage issue after many submissions so I would like to have a option to clear the installers via the application itself.

Solution

add some command like wingetcreate cache clean to clear the installers.
(optional)
some extra commands like wingetcreate cache --list will display all the installers that wingetcreate downloaded. Doesn't have to be exact appname just the installer's name. Output could look similar to when we type dir command in a folder. This feature could be easily added if wingetcreate stored installers in it's own directory somewhere instead of %temp% folder so that it can just clone what dir command does.

Parsing msixbundle generates installer node for resource packages

Brief description of your issue

We generate an installer node in the installers manifest for each "architecture" in the bundle, including for Neutral resource packages. We shouldn't generate nodes for resource packages though.

Steps to reproduce

wingetcreate new https://github.com/files-community/Files/releases/download/v1.5/Files-1.5.Msixbundle

Expected behavior

There should be 3 nodes in the installers manifest: x64, x86, and arm64

Actual behavior

We get 4 nodes, the above three and a Neutral one

Unhandled exception. System.FormatException: Input string was not in a correct format.

Unhandled exception. System.FormatException: Input string was not in a correct format.
at System.Text.ValueStringBuilder.ThrowFormatError()
at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.Format(String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
at Microsoft.WingetCreateCLI.Program.Main(String[] args)
at Microsoft.WingetCreateCLI.Program.

(String[] args)

Add support for arguments in manifest

Description of the new feature/enhancement

Oculus and some other programs need a / argument to run silent mode. This can not be done with winget right now

Proposed technical implementation details (optional)

When using the wingetcrete the should be a argument option were i can add / commands

Unhandled exception. System.FormatException: Input string was not in a correct format.

Unhandled exception. System.FormatException: Input string was not in a correct format.
at System.Text.ValueStringBuilder.ThrowFormatError()
at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.Format(String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
at Microsoft.WingetCreateCLI.Program.Main(String[] args)
at Microsoft.WingetCreateCLI.Program.

(String[] args)

Installer download fails when download URLs are HTTP redirects

Brief description of your issue

The tool does not process download URLs that are redirects to another URL.

Steps to reproduce

Run winget new and enter URL https://download.qt.io/official_releases/qtcreator/4.15/4.15.0/qt-creator-opensource-windows-x86_64-4.15.0.exe

Expected behavior

The tool should follow the redirect (but insert the original URL in the manifest).

Actual behavior

The tool fails with error

Failed to download installer.
HTTP response was unsuccessful. Status code: Redirect

Environment

Windows Manifest Creator v0.1.0.1

Support publishing to REST API source

I would like to be able to use this tool to publish manifest data to a REST API based source.

Add custom options for silent installation (exe files)

Description of the new feature/enhancement

When you use wingetcreate new for an exe file, sometimes you should add an argument to make the installation silently. So we have to think how to solve the warn: Did you forget to add Silent or SilentWithProgress switches?

`wingetcreate update` different `InstallerType`

Brief description of your issue

When you do wingetcreate update --id --version --url https://endswith.msi on a manifest which have https://endwith.exe the InstallerType and InstallerSwitches will remain with the exe switches.

Steps to reproduce

wingetcreate update -i TechSmith.Camtasia -v 21.0.4.31371 -u https://download.techsmith.com/camtasiastudio/releases/2104/camtasia.msi

Expected behavior

Replace the EXE Installer or keep the EXE installer (try to update it) and add the MSI installer.

Actual behavior

Only replaces InstallerUrl and InstallerSha256

Environment

Windows Manifest Creator v0.1.0.1

Windows Package Manager Manifest Creator version? (wingetcreate.exe -?)

Any other software?

Set up Community Profile

Add files for community profile.

README.md
SECURITY.md
CODE_OF_CONDUCT.md
CONTRIBUTING.md
LICENSE
Issue Templates

• Issue-Bug
• Issue-Feature
• Issue-Docs

Pull Request Template

Telemetry opt-out

At Microsoft, we care deeply about handling telemetry consent appropriately. As the winget-create tool does not have settings like the complementary Windows Package Manager, we are going to add a "first run" feature to provide an opt-out mechanism. This is in addition to the currently supported behavior associated with Windows telemetry. Even if the Windows settings permit telemetry, the winget-create tool will allow users to opt-out.

`wingetcreate new` if PackageIdentifier exists

Description of the new feature/enhancement

if wingetcreate new detects a duplicate/existing PackageIdentifier it should use the Metadata from the newest Manifest.

Proposed technical implementation details (optional)

Use the Metadata from the newest Manifest like wingetcreate update. And add the missing Metadata.

`wingetcreate update` does not update the ProductCode and will keep the previous one like wingetbot.

Description of the new feature/enhancement

wingetcreate update does not update the ProductCode and will keep the previous one like wingetbot.

#19 (comment)

Proposed technical implementation details (optional)

Add JSON schema to manifests

Description of the new feature/enhancement

I'd like to have the appropriate JSON schema added to manifest YAML files so I can use an IDE like Visual Studio Code that supports JSON schema validation, tooltips, and autocomplete.

Proposed technical implementation details (optional)

Include the appropriate schema as the first line in the file(s) generated.

# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.0.0.schema.json
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultlocale.1.0.0.schema.json
# yaml-language-server: $schema=https://aka.ms/winget-manifest.locale.1.0.0.schema.json
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.0.0.schema.json

Update command: Bad behavior if existing manifest has multiple installer URLs and a URL is provided on cmd-line

Brief description of your issue

For the Update command, if the existing manifest in winget-pkgs has multiple installer urls, we'll get bad behavior if the URL doesn't specify a URL on the command line.

Steps to reproduce

update -i Microsoft.PowerShell -u https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x64.msi

Expected behavior

Error message indicating that multiple URLs are not supported.

Actual behavior

Update "succeeds" and produces an installer manifest with two nodes with the same URL, but different archs and hashes

Calculated installer hash incorrect for sourceforge.net URLs

Brief description of your issue

The installer hash included by the tool is incorrect for download URLs from sourceforge.net. So far for every URL I tried, the hash was incorrect.

Steps to reproduce

Run for example wingetcreate.exe new http://sourceforge.net/projects/ufraw/files/ufraw/ufraw-0.19.2/ufraw-0.19.2-2-setup.exe/download

Expected behavior

The installer hash should be 5BC7A132CA7483AACD09D00AC0D6DDA106D585FE227AF4EF34DABC9EE81A9844. This is also the hash that manifest validation expects, and the hash returned by

$stream = (New-Object System.Net.WebClient).OpenRead($Uri)
Get-FileHash -InputStream $stream -Algorithm SHA256

Actual behavior

The installer hash is incorrectly calculated as 41005A837D2EBF343F851815E0F6CF2BF1A64F58CDEF68D54CE8352F9008F7B7.

Environment

Windows Package Manager Manifest Creator v0.1.0.1

Narrator announces complete line on typing each character or hitting enter key at any input field

Narrator is announcing the complete line while typing each character.

For example:
When a user types a character for ‘Package unique identifier’ field, narrator announces the typed character followed by the complete field name([PackageIdentifier] The package unique identifier…….) which is too verbose and noisy.

The same issue can be observed for each prompt and when selecting the default value by just hitting Enter. This can also cause issues when trying to consume content line by line using the arrow key on narrator as too much is printed in the output for the screen reader.

Any suggestions as to how we can format the question better so that the prompt is more accessible or any alternative solution to modifying the narrator to be more user friendly would be kindly appreciated :)

Multiple URL support

Description of the new feature/enhancement

Add the possibility to add more than one installer in wingetcreate new and either wingetcreate update

Proposed technical implementation details (optional)

I think this is a low priority feature request, so keep calm and develop the rest 😆
I didn't saw the source code, so I'm ignorant

`wingetcreate update` should change the InstallerType and SilentSwitches if it detects a compatible InstallerType

Description of the new feature/enhancement

wingetcreate update should change the InstallerType and SilentSwitches if it detects a compatible InstallerType.

#19

Proposed technical implementation details (optional)

wingetcreate is disappointing

wingetcreate is disappointing from what it sounded like it should have been..

What i like

• wincreate new will detect the InstallerType automatically
• wincreate new will suggest pretty good metadata

What i don't like

• wingetcreate is not user-friendly
• wingetcreate feels weird, why is it not winget create?
• wingetcreate new give way too few questions
• wingetcreate update --id does... nothing? if the manifest does not use a dynamic url. if -v -u -s is not inputted it should prompt for the information.
• wingetcreate update does not prompt to update any of the information
• wingetcreate update should change the InstallerType and SilentSwitches if it detects a compatible InstallerType
• wingetcreate update does not update the ProductCode and will keep the previous one like wingetbot.

I will be sticking to YamlCreate.ps1

`wingetcreate update` should not be case-sensi-weird

Brief description of your issue

I was trying to update node.js to the latest ver of of the 14.x branch, but by running winget show openjs.nodejs --versions I noticed its missing 14.16.1 and 14.17.0.

So I tried submitting it:

PS C:\Users\mnpen> wingetcreate new https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
Downloading and parsing: https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi...

This tool will walk you through a series of questions to help you create your package manifest.

For information about the restrictions for each field, visit https://github.com/microsoft/winget-cli/blob/master/doc/ManifestSpecv1.0.md

Press ENTER to submit the value for each question including accepting the (default) value.

Please enter values for the following fields:
 [PackageIdentifier] The package unique identifier |e.g. Microsoft.VisualStudio|: OpenJS.Nodejs
 [PackageVersion] The package version |e.g. 1.2.3.4|: 14.17.0
 [DefaultLocale] The package meta-data default locale |e.g. en-US|: en-US
 [Publisher] The publisher name |e.g. Microsoft|: Node.js Foundation
 [PackageName] The package name |e.g. Visual Studio|: Node.js
 [License] The package license |e.g. MIT License|:

OK... it doesn't seem to be recognizing that this is an existing package. Maybe there's a different command for updating the existing package? I cancel out, run wingetcreate --help, ahah, yes, of course there is, it's called update.

PS C:\Users\mnpen> wingetcreate update -i OpenJS.Nodejs -u https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
A GitHub account or personal access token must be linked in order to continue with this command.
Execution of the command is paused until the GitHub login has been completed.

Initiating GitHub login...

Launching web browser... If default web browser does not launch, please go to: https://github.com/login/device
Please enter the following user verification code when prompted: <bleep>

Resuming command execution...
Retrieving latest manifest for OpenJS.Nodejs
ERROR: repos/microsoft/winget-pkgs/contents/manifests/o/OpenJS/Nodejs was not found.
Please check the spelling and casing of the package identifier

Well that's really weird because when I run winget list it explicitly says I have OpenJS.Nodejs installed:

Node.js                                  OpenJS.Nodejs                                        14.16.1             16.2.0       winget

So I go to github to try and figure out what it's actually listed as. I find https://github.com/microsoft/winget-pkgs/tree/master/manifests/o/OpenJS/NodeJS and try again, changing it to capital JS to match the github URL. And indeed, that seems to have found something:

PS C:\Users\mnpen> wingetcreate update -i OpenJS.NodeJS -u https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi
Using GitHub token from cache...
Retrieving latest manifest for OpenJS.NodeJS
Downloading and parsing: https://nodejs.org/dist/v14.17.0/node-v14.17.0-x64.msi...

Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate

PackageIdentifier: OpenJS.NodeJS
PackageVersion: 16.2.0
DefaultLocale: en-US
ManifestVersion: 1.0.0
...

But it thinks its 16.2.0 for some reason and doesn't even prompt to ask otherwise. But maybe that's issue #23 ?

Anyway, I'm calling this sensi-weird because it does appear to be case-sensitive but it doesn't match the case that winget list shows, so that's kinda weird.

Steps to reproduce

Try running wingetcreate update -i using an existing package but "wrong" case.

Expected behavior

Just do a case-insensitive match. If different packages are allowed to have the same name but in different cases, that's going to be a whole 'nother problem.

And also, maybe a separate issue, but make winget list show the actual ID in the ID column.

Actual behavior

Doesn't match

Environment

Windows Manifest Creator v0.1.0.1

Remove x86 package from msixbundle

Description of the new feature/enhancement

Our msixbundle includes x64 and x86 msix packages. According to our telemetry, we haven't yet seen any x86 users, and we feel it's unlikely that we'll have any, given that our users are generally in the developer class. Removing the x86 package from the bundle would halve the download size for all our users.

If no one hollers in opposition to this after a while, we'll make the change.

Proposed technical implementation details (optional)

Remove x86 package from bundle, but keep the deployment as an msixbundle, as we may have other platforms in the future (arm64?)

Unhandled exception. System.FormatException: Input string was not in a correct format.

The following is the error I'm getting

Unhandled exception. System.FormatException: Input string was not in a correct format.
   at System.Text.ValueStringBuilder.ThrowFormatError()
   at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.Format(String format, Object[] args)
   at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
   at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)
   at Microsoft.WingetCreateCLI.Program.<Main>(String[] args)

I was trying to submit Exodus using wingetcreate. After generating the manifest I have tested the manifest by using this command winget install --manifest "C:\Users\xxx\manifests\e\Exodus\exodus\21.5.25". The application has been successfully installed but when I tried to submit the manifest this error popped out. Please help me out to resolve it.

Unhandled exception. System.FormatException: Input string was not in a correct format.

Hello while making a manifest file for Docker I received the following error:

Unhandled exception. System.FormatException: Input string was not in a correct format.
   at System.Text.ValueStringBuilder.ThrowFormatError()
   at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
   at System.String.Format(String format, Object[] args)
   at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
   at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)
   at Microsoft.WingetCreateCLI.Program.<Main>(String[] args)

Steps to reproduce

1. Enter URL: https://desktop.docker.com/win/stable/amd64/Docker%20Desktop%20Installer.exe
2. Press enter 7 times until you get to ShortDescription
3. Change short description to Docker Desktop for Windows
4. Press Enter
5. Would you like to make changes? Press Y and then Enter
6. Press Enter for the remaining questions
7. Then press Y and Enter to submit to package manager repository
8. Fill in the github code and Enter
9. Fill in Password and press Enter
10. Then error shows up

"New" command should allow editing of architecture, since we may get it wrong

Brief description of your issue

When we parse an exe installer, we get the architecture of the installer, which may not be the same as that of the app. As such, we should allow the user to edit the architecture, currently there's no way to do that.

Steps to reproduce

wingetcreate new http://www.sqliteexpert.com/v5/SQLiteExpertPersSetup64.exe

Expected behavior

Installer manifest should have x64 architecture

Actual behavior

Manifest has x86 architecture, since that's the arch of the installer itself

Is this a UWP app or win32 app?

Winget-create can "use all system resources", which shows that winget-create is a win32 app.
However, why does it need "access your internet connection" capability besides from using all system resources?

Add the licence-url field

Description of the new feature/enhancement

Add the licence-url field (and remove it when is blank) when submitting a new program

Update Command does not show warning when forgetting to include --url flag.

Update command fails to show the user an error message when they forget to include the --url flag when specifying the installer URL.

Expected behavior:
Show an error message to include the flag or that the format of the parameter is incorrect.

Allow to sign commits

Description of the new feature/enhancement

Allow us to sign commits which is now marked as unverified

`wingetcreate update` should change the InstallerType and SilentSwitches if it detects a compatible InstallerType

Description of the new feature/enhancement

wingetcreate update should change the InstallerType and SilentSwitches if it detects a compatible InstallerType.

#19

Proposed technical implementation details (optional)

Build automation to publish to Windows Package Manager repository

Description of the new feature/enhancement

Automate publishing to the Windows Package Manager repository:
https://github.com/microsoft/winget-pkgs

Proposed technical implementation details (optional)

Extend release pipeline to submit the manifest for the winget-create package.

wingetcreate should prompt for optional fields.

Description of the new feature/enhancement

The Windows Package Manager Manifest Creator should prompt users for optional fields like "InstallerSuccessCodes".

microsoft/winget-pkgs#14224

Proposed technical implementation details (optional)

After the required fields for a "valid" manifest has been created, the user should be prompted if they would like to add optional fields. If this is an "update" command, the current values should be displayed so they can be validated/modified.

`wingetcreate new` detected installertype that fails

Brief description of your issue

wingetcreate new detected the wrong installertype which made winget install -m M:\pathtomanifest fail with error code 1620

Steps to reproduce

wingetcreate new https://www.expressvpn.works/clients/windows/expressvpn_windows_10.2.4.11_release.exe

winget install -m .\e\ExpressVPN\ExpressVPN\10.2.4.11\

Expected behavior

For it to work

Actual behavior

Error code 1620

Environment

Windows Package Manager Manifest Creator version? (wingetcreate.exe -?)

Any other software?

`wingetcreate new` ignores already existing folder structure.

Brief description of your issue

wingetcreate new ignores the existing folder structure and can cause major issues.

Steps to reproduce

microsoft/winget-pkgs#14367
wingetcreate new voidtools.everything url

Actual behavior

Creates the manifests in manifests/v/voidtools/everything/1.4.1.1005

Expected behavior

To create the manifest in manifests/v/voidtools/Everything/1.4.1.1005

Environment

Windows Manifest Creator v0.1.0.1

Windows Package Manager Manifest Creator version? (wingetcreate.exe -?)

Any other software?

Unhandled exception. System.FormatException: Input string was not in a correct format.

pls help
Unhandled exception. System.FormatException: Input string was not in a correct format.
at System.Text.ValueStringBuilder.ThrowFormatError()
at System.Text.ValueStringBuilder.AppendFormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at System.String.Format(String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Log(LogLevel level, String format, Object[] args)
at Microsoft.WingetCreateCLI.Logging.Logger.Error(String message, Object[] args)
at Microsoft.WingetCreateCLI.Program.Main(String[] args)
at Microsoft.WingetCreateCLI.Program.

(String[] args)

Update command shouldn't submit PR if there's no changes

Brief description of your issue

When wingetcreate update is run with just a packageId, it'll fetch the package at the current URL, hash it, and submit an update PR. This makes sense if the URL is a vanity URL and the version is "latest", but not in other cases. For example, see this PR microsoft/winget-pkgs#17720 (comment)

Steps to reproduce

wingetcreate update GitHub.cli -s

Expected behavior

Aborts after determining that there's no substantial changes to be made

Actual behavior

Downloads package at current URL, hashes it (resulting in the same hash), and submits a PR with no real changes

wingetcreate should not allow submission when the application already exists.

Description of the new feature/enhancement

wingetcreate should not allow submission of already existing manifest.

Proposed technical implementation details (optional)

Use sha256 for identifying.

Add ProductCode input (maybe automatically)

Description of the new feature/enhancement

In some MSIs, like chrome, it will be necessary to insert a "product code", otherwise winget will not recognise the updates.

Proposed technical implementation details (optional)

(I don't know how to get it for the winget-create, but manually you can get it from "winget list" when the app is already installed. If I find something, I will add down here

Photos

`wingetcreate update` if latest InstallerUrl

Description of the new feature/enhancement

wingetcreate update should delete the old version folder if it uses the same InstallerUrl and count as Update and Rename so we or the bot don't have to clean up the folder afterwards.

Installer hash does not match

Brief description of your issue

If creating a manifest file, and then needing to update it, due to a new version getting released, you need to remember to delete the original file from the temp folder.
I double checked several times, the file in temp IS updated to the new version, yet if I do not delete it before the second wingetcreate it fails when you validate the manifest using winget install.
I have tested this in 2 different machines with same result.

Steps to reproduce

wingetcreate new https://github.com/open-rpa/openrpa/releases/download/1.2.47/OpenRPA.msi
wingetcreate new https://github.com/open-rpa/openrpa/releases/download/1.2.48/OpenRPA.msi
winget install --manifest manifests\o\OpenRPAApS\OpenRPA\1.2.48.0

if you how ever delete the file from temp, it works

wingetcreate new https://github.com/open-rpa/openrpa/releases/download/1.2.47/OpenRPA.msi
del %temp%\openrpa.msi
wingetcreate new https://github.com/open-rpa/openrpa/releases/download/1.2.48/OpenRPA.msi
winget install --manifest manifests\o\OpenRPAApS\OpenRPA\1.2.48.0

Expected behavior

Not needing to delete the file in temp

Actual behavior

Environment

Windows Manifest Creator v0.1.0.1

Simplify localization for existing packages

New commands and arguments to help with localization

As someone who prefers a language other than American English (en-US) I want to be able to add or modify localized content to manifests so I can read descriptions in my preferred language.

Proposed technical implementation details (optional)

Two new commands: wingetcreate new-locale and wingetcreate update-locale

wingetcreate new-locale

wingetcreate new-locale <PackageIdentifier>
Targets the latest version, and asks the user for the locale they would like to provide. If the locale is already present, the user should be prompted to use wingetcreate update-locale.

If the locale is not present then it provides the default locale for reference so the user can interactively provide the localized content for an additional locale.

wingetcreate update-locale

wingetcreate update-locale <PackageIdentifier>
Targets the latest version, and asks the user for the locale they would like to provide. If the locale is not already present, the user should be prompted to use wingetcreate new-locale.

If the locale is present then it provides the default locale and the current localized content so the user can interactively provide modified localized content for the locale.

Additional arguments

--locale <locale>: Specify the locale to add or update.
--reference-locale <locale>: Specify the locale for comparison other than the default locale.
--version <version>: Specify the version for an earlier version of the package .