microsoft / microsoft/winget-cli

Can't install Microsoft.DotNet.DesktopRuntime.8 (x64) when Microsoft.DotNet.DesktopRuntime.8 (x86) is installed

Open
#5,731 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Area-Architecture Command-Install Issue-Bug
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

Relevant area(s)

WinGet CLI

Relevant command(s)

No response

Brief description of your issue

I have machine where I use various versions of .NET

I wanted to install Microsoft.DotNet.DesktopRuntime.8 with x64 architecture.
Unfortunately it was skipped, as it detected that I have already it installed.

But that's wrong as I have Microsoft.DotNet.DesktopRuntime.8 installed but with x86 architecture

Seems winget is confused when there are same packages but with different architectures installed

Steps to reproduce
  • winget install Microsoft.DotNet.DesktopRuntime.8 --architecture x64 - installed
  • winget install Microsoft.DotNet.DesktopRuntime.8 --architecture x86 - skipped
Expected behavior

Winget should allow for installing both Microsoft.DotNet.DesktopRuntime.8 x64 and Microsoft.DotNet.DesktopRuntime.8 x86 packages

Actual behavior

Winget doesn't allow for installing same package with different architectures

Environment
winget --info
Windows Package Manager v1.11.430
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.5909
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.430.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the reported behavior with the two winget install commands and compare package detection for the x86 and x64 architectures. Trace the WinGet CLI package-detection and installation entry points to identify why an installed package of one architecture suppresses the other; done means both architectures can be installed and the behavior is covered by a regression test.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
cli, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.