Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong architecture parsed from installer #467

Open
Eddga opened this issue Oct 28, 2023 · 3 comments
Open

Wrong architecture parsed from installer #467

Eddga opened this issue Oct 28, 2023 · 3 comments

Comments

@Eddga
Copy link

Eddga commented Oct 28, 2023

Brief description of your issue

I just tried to update the ElectronicArts.EADesktop app via wingetcreate update interactive mode and the validation failed - see #123938
I then noticed that wingetcreate update recognized it as being x86 while EA Desktop is a x64 only app.
Also when you do wingetcreate.exe update --urls https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EAappInstaller.exe --version 13.52.0.5565 ElectronicArts.EADesktop it will throw an error:

Each new installer URL must have a single match to an existing installer based on architecture, installer type and scope. The following installers failed to match an existing installer:
Multiple matches found for X86 Burn installer detected from the url: https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EAappInstaller.exe
Try using the architecture and/or scope overrides to uniquely match new URLs to existing installer nodes in the manifest.

It only works when you use architecture override.

Steps to reproduce

wingetcreate update ElectronicArts.EADesktop -i
with version 13.52.0.5565 and URL https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EAappInstaller.exe
OR
wingetcreate.exe update --urls https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EAappInstaller.exe --version 13.52.0.5565 ElectronicArts.EADesktop

Expected behavior

Parse the architecture correctly as x64

Actual behavior

Parses architecture as x86

Environment

Windows Package Manager Manifest Creator v1.5.5.0

Windows: Windows.Desktop v10.0.22621.2506
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0
@mdanish-kh
Copy link
Contributor

The happens when the installer's architecture differs from the installed application architecture. WinGet parses the installer binary for architecture if it can't detect it from the URL / user provides the override. This is related to #118 (comment)

Work needs to be done to allow interactive mode to handle these scenarios:

@Eddga
Copy link
Author

Eddga commented Oct 28, 2023

Thanks for your answer @mdanish-kh! 👌
I see. I already thought of this. Is there an easy way for me to check if the installer's architecture?

@mdanish-kh
Copy link
Contributor

mdanish-kh commented Oct 30, 2023

Is there an easy way for me to check if the installer's architecture?

I'm afraid I'm not aware of such. From discussions in #118, I learned that Inno Setup is a 32-bit application which means a number of installers created by that framework would be 32-bit. Other than that I'm not aware of an easy method to check that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants