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.

Sign up for GitHub

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

Jump to bottom

Wix and MSI not considered equal #2565

Closed
Trenly opened this issue Sep 30, 2022 · 0 comments · Fixed by #4740
Closed

Wix and MSI not considered equal #2565

Trenly opened this issue Sep 30, 2022 · 0 comments · Fixed by #4740
Labels
Command-Upgrade Issue related to WinGet Upgrade In-PR Issue related to a PR Issue-Bug It either shouldn't be doing this or needs an investigation.
Milestone
1.9 Client

Comments

@Trenly
Copy link
Contributor

Trenly commented Sep 30, 2022

Brief description of your issue

When both WIX and MSI are specified in the manifest, architecture may be disregarded if the install technology is detected as MSI. This causes issues when packages require specific architecture to run

Steps to reproduce

  • Open a new 64-bit VM / Sandbox
  • winget install Tortoisesvn -v 1.14.29387
  • winget upgrade tortoisesvn --verbose-logs

Expected behavior

Application to be upgraded successfully

Actual behavior

2022-09-30 14:03:09.828 [CLI ] Starting installer selection.
2022-09-30 14:03:09.828 [CLI ] Installer [X64,wix,Machine,en-US] is current best choice
2022-09-30 14:03:09.828 [CLI ] Installer [X86,msi,Machine,en-US] is better than [X64,wix,Machine,en-US] due to: Installed Type
2022-09-30 14:03:09.828 [CLI ] Installer [X86,msi,Machine,en-US] is current best choice
2022-09-30 14:03:09.828 [CLI ] Installer [Arm64,msi,Machine,en-US] not applicable: Machine is not compatible with Arm64

Application cannot be installed as 32-bit installer will not run on x64

Environment

PS C:\Windows\system32> winget --info
Windows Package Manager v1.3.2091
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.2006
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2091.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
@ghost ghost added the Needs-Triage Issue need to be triaged label Sep 30, 2022
@denelon denelon added Issue-Bug It either shouldn't be doing this or needs an investigation. and removed Needs-Triage Issue need to be triaged labels Oct 3, 2022
@denelon denelon added this to the v1.5-Client milestone Feb 14, 2023
@denelon denelon modified the milestones: v1.5-Client, v.Next-Client Apr 18, 2023
@mdanish-kh mdanish-kh mentioned this issue Jul 14, 2023
Closed
@Trenly Trenly mentioned this issue Sep 22, 2023
Closed
@denelon denelon modified the milestones: v.Next-Client, v1.7 Client Sep 22, 2023
@denelon denelon added the Command-Upgrade Issue related to WinGet Upgrade label Sep 22, 2023
@denelon denelon added this to WinGet Jan 3, 2024
@denelon denelon modified the milestones: v1.7 Client, 1.8 Client Feb 28, 2024
@sba923 sba923 mentioned this issue May 21, 2024
Closed
@denelon denelon modified the milestones: 1.8 Client, 1.9 Client Jun 11, 2024
@JohnMcPMS JohnMcPMS mentioned this issue Aug 19, 2024
Merged
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR Issue related to a PR label Aug 19, 2024
JohnMcPMS added a commit that referenced this issue Aug 20, 2024
@JohnMcPMS
Remove preference for "installed" installer type (#4740)
dc1435a 
Fixes #2565 

## Change
Move (and rename) the `InstalledTypeComparator` from being a comparator
to just a filter. Given what we can (or rather, currently do) actually
discern from system state, it doesn't make sense to give preference to
the few types that we use to signify the compatibility sets. If we truly
want to preserve installer type selection within a compatibility set, we
need to store the user selection into the tracking database similar to
`UserIntentArchitecture`.
@github-project-automation github-project-automation bot moved this to Done in WinGet Aug 20, 2024
@denelon denelon moved this from Done to Released in WinGet Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Command-Upgrade Issue related to WinGet Upgrade In-PR Issue related to a PR Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
WinGet
Status: Released
Milestone
1.9 Client
Development

Successfully merging a pull request may close this issue.

Remove preference for "installed" installer type JohnMcPMS/winget-cli
2 participants
@Trenly @denelon