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

wingetcreate new detected installertype that fails #26

Closed
OfficialEsco opened this issue May 26, 2021 · 5 comments · Fixed by #73
Closed

wingetcreate new detected installertype that fails #26

OfficialEsco opened this issue May 26, 2021 · 5 comments · Fixed by #73

Comments

@OfficialEsco
Copy link

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?
@ghost ghost added the Needs-Triage label May 26, 2021
@OfficialEsco OfficialEsco changed the title wingetcreate new detected installertype that fails wingetcreate new detected installertype that fails May 26, 2021
@arjun-msft arjun-msft assigned arjun-msft and ryfu-msft and unassigned arjun-msft May 26, 2021
@arjun-msft arjun-msft added this to the v1.0 - `winget create` milestone May 26, 2021
@palenshus
Copy link
Contributor

Very strange indeed. From the exe manifest, this does seem to be a WiX installer:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity name="setup.exe" version="1.0.0.0" processorArchitecture="x86" type="win32"/>
    <description>WiX Toolset Bootstrapper</description>

However, winget fails when trying to install it as such. Changing wix to exe in the installer manifest seems to fix the issue. It's possible either this is an extremely rare edge case where the workaround of manually editing the manifest is sufficient, or it's possible there's something wrong with our installerType detection heuristic.

@OfficialEsco
Copy link
Author

EA Desktop also does the same
https://origin-a.akamaihd.net/EA-Desktop-Client-Download/installer-releases/EADesktopInstaller.exe
But i do believe the EULA switch works, so it IS a wix installer, however when i have the InstallerType: wix and the Silent parameter /silent which "works(?)" the installer comes with a error..

I don't know how installers work, but do they disable the parms for some wild reason?

@palenshus
Copy link
Contributor

Apparently, the "wix" installerType is actually for WiX MSIs. When the WiX toolset is used to create an exe, that's actually a "burn" installer. https://wixtoolset.org/documentation/manual/v3/bundle/

@OfficialEsco
Copy link
Author

Apparently, the "wix" installerType is actually for WiX MSIs. When the WiX toolset is used to create an exe, that's actually a "burn" installer. https://wixtoolset.org/documentation/manual/v3/bundle/

burn did indeed solve the EA Desktop InstallerType, hope there is a easy way to detect the difference between burn and WiX MSI :)

@palenshus
Copy link
Contributor

We decided to just set the installerType for all MSIs as "msi" for now. Winget itself doesn't treat them differently: https://github.com/microsoft/winget-cli/blob/cf6f8e58195bf033a1a5872f7b800866cd27a586/src/AppInstallerCommonCore/Manifest/ManifestCommon.cpp#L348. If that ever changes, we'll re-evaluate

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

Successfully merging a pull request may close this issue.

5 participants