wingetcreate looks for installer architecture instead of application architecture

[ldennington]

Brief description of your issue

To replace my team's current custom tooling for deploying to winget, I am trying to adopt wingetcreate for automatic updates of the Microsoft.Git manifest each time we release. The manifest currently has one installer and specifies an x64 architecture. Note that this refers to the application to be installed not the installer itself (which is x86).

When we attempt to publish a new manifest, wingetcreate downloads the installer and detects that the installer is x86. It then compares it to the x64 specified in the manifest and fails. I've included more details below, but in short I think wingetcreate is matching on installer architecture when it should be matching on application architecture.

Steps to reproduce

Pre-Requisites

1. Use a Windows 10 machine
2. Ensure winget and wingetcreate are installed and on the path
3. Generate a PAT that has repo:public_repo scope

Steps to Reproduce

Run the following command (replacing *** with the token you generated above):

wingetcreate update Microsoft.Git -u https://github.com/ldennington/git/releases/download/v2.33.0.vfs.0.7/Git-2.33.0.vfs.0.7-64-bit.exe -v 2.33.0.0.7 -o manifests -t ***

Expected behavior

I expected the Microsoft.Git manifest to be updated successfully and saved to the manifests directory.

Actual behavior

The following error is thrown:

Each new installer URL must have a single match to an existing installer based on installer type and architecture. The following installers failed to match an existing installer:
Multiple matches found for X86 Inno installer detected from the url: https://github.com/ldennington/git/releases/download/v2.33.0.vfs.0.7/Git-2.33.0.vfs.0.7-64-bit.exe

I tried to update the architecture to x86 in the manifest, but that broke winget validation (which makes sense since x64 applications can't run on x86 machines). So I don't actually think this was the right fix. My understanding is that Inno Setup only ships an x86 version, and it's only possible to create x86 Inno installers using this tech, so I would expect this issue to impact a lot of products beyond just Microsoft.Git.

In light of this, I believe that wingetcreate should be looking at the application architecture instead of the installer architecture when attempting to find an installer match.

Environment

Windows Package Manager Version: v1.1.12701
Windows OS Build: 19043.1288
wingetcreate Version: 0.4.2.1
Package: Microsoft.Git

[jedieaston]

This is also extremely important to fix for nullsoft installers, since all of their installer executables are x86, even if they install a x64 application.

[palenshus]

AFAIK the only way to get the application arch is by installing it. If you know of another way please let us know though! If it's not possible, then the alternative is to allow the user to override the detected installer, and/or to improve our URL parsing. In this case, adding "64-bit" to the URL parsing would resolve it, which we should do:

winget-create/src/WingetCreateCore/Common/PackageParser.cs

Line 466 in 7c61f3e

if (Regex.Match(url, "x64|win64|_64", RegexOptions.IgnoreCase).Success)

I filed #199 to track that change

[ldennington]

Thank you so much!! I'd be happy to contribute this change if you'd like.

[jedieaston]

If you know of another way please let us know though

Would you be opposed to extracting the installer somehow (there's three or four projects that do this for Inno, innoextract and innounp seem to work great) and checking to see if there are any 64-bit binaries inside of it? If there were, you could conclude that it was a 64-bit installer.

Granted, wingetcreate would probably have to have it's own extractor so you don't have to run other binaries, but it would be one way of solving it (probably not the best way, especially if ISVs name their installers correctly as https://github.com/microsoft/git has).

[denelon]

Thank you so much!! I'd be happy to contribute this change if you'd like.

We would love a contribution 👍

[palenshus]

Would you be opposed to extracting the installer somehow (there's three or four projects that do this for Inno, innoextract and innounp seem to work great)...

We're definitely not inherently opposed to using 3rd-party libraries, but unfortunately my brief inspection seems to show these only distributed as exes, w/o DLLs that we could pinvoke into, and I couldn't find any .NET libraries either. Packaging additional exes into winget-create is not ideal. I didn't look into the source to see how difficult it is. If it's something you're familiar with and would like to tackle that'd be fantastic!

[ryfu-msft]

@ldennington,

I have already merged the changes for improving our URL parsing to better detect the architecture from your provided installer URL. Your problem should be resolved when we push out our next release soon. Thanks for bringing this issue to our attention and I apologize for the inconvenience it may have caused you!

[ldennington]

@ryfu-msft Awesome thanks so much for the fast fix!! Looking forward to the next release 😊.