Valid wingetcreate update fails with "New package found for Nullsoft X86 installer, but not found in existing manifest"

[apetresc]

Brief description of your issue

I am attempting to use wingetcreate to update an existing manifest for SabakiHQ.Sabaki. The update is to a new minor version that matches the same installer types as the existing one (they are produced by the same build pipeline). However, the update fails after validating both provided installers with the following:

PS C:\Users\apetresc\src\winget\winget-create> .\src\WingetCreateCLI\bin\x64\Debug\net5.0-windows10.0.17763.0\WingetCreateCLI.exe update SabakiHQ.Sabaki -v 0.52.0 -u "https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-x64-setup.exe" "https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-ia32-setup.exe"

Retrieving latest manifest for SabakiHQ.Sabaki
Downloading and parsing: https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-x64-setup.exe...

Downloading and parsing: https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-ia32-setup.exe...

Updating a manifest is only supported with the same number of installer URLs, and the same installer types and architectures
New package found for Nullsoft X86 installer, but not found in existing manifest

Steps to reproduce

Simply the call above:

PS C:\Users\apetresc\src\winget\winget-create> .\src\WingetCreateCLI\bin\x64\Debug\net5.0-windows10.0.17763.0\WingetCreateCLI.exe update SabakiHQ.Sabaki -v 0.52.0 -u "https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-x64-setup.exe" "https://github.com/SabakiHQ/Sabaki/releases/download/v0.52.0/sabaki-v0.52.0-win-ia32-setup.exe"

Expected behavior

Since the provided URLs do match the existing manifest's types and architecture (nullsoft x64 and x86 respectively), I expected wingetcreate to match them and generate an updated manifest.

Actual behavior

It somehow fails to reconcile the installers even though they should match, and spits out that unhelpful error without providing any details of what it thinks the mismatch is.

Environment

PS C:\Users\apetresc\src\winget\winget-create> .\src\WingetCreateCLI\bin\x64\Debug\net5.0-windows10.0.17763.0\WingetCreateCLI.exe -?
Windows Manifest Creator v0.3.0.0

I'm using my own build of the latest master to work around #90 which hasn't been released yet.

[palenshus]

One possible solution:

Attempt to parse architecture from URL (in this case, x64 and ia32), and if present, override architecture detected from binary. If we do this, we'd want to log a warning so that users are alerted to the mismatch. This would also hopefully spur them to generate the correct architectures in their installers going forward.

[apetresc]

So, based on your response, am I interpreting correctly that the detected architectures for this set of binaries is something other than x86 + x64? Why would that be? Those are the correct architectures for those particular installers, as far as I can tell.

[palenshus]

Yep, exactly. Unfortunately we see this quite often, where an x64 app has an x86 exe installer. (Also common is an x64 app with an MSI that doesn't declare x64)

You can verify this yourself with dumpbin /headers <exe>

[apetresc]

Oh, interesting. This particular installer was just generated with electron-builder, I never even considered the question of what architecture the installer itself is. I'll check to see if there's a way to configure that in the flags to electron-builder. But yeah, the installed program's architecture is still correct.

[palenshus]

Ah, good to know! If you figure it out, please report back, others might be able to benefit from your investigation, thanks!