Open Eddga opened 8 months ago
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 https://github.com/microsoft/winget-create/issues/118#issuecomment-902193284
Work needs to be done to allow interactive mode to handle these scenarios:
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?
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 https://github.com/microsoft/winget-create/issues/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
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:It only works when you use architecture override.
Steps to reproduce
wingetcreate update ElectronicArts.EADesktop -i
with version13.52.0.5565
and URLhttps://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EAappInstaller.exe
ORwingetcreate.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