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

[Package Issue]: Microsoft.DotNet.* #117876

Open
2 tasks done
Killom opened this issue Aug 23, 2023 · 9 comments
Open
2 tasks done

[Package Issue]: Microsoft.DotNet.* #117876

Killom opened this issue Aug 23, 2023 · 9 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@Killom
Copy link

Killom commented Aug 23, 2023

Please confirm these before moving forward

  • I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
  • I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Side-By-Side installation.

Brief description of your issue

Not sure if this is package or winget related. Please move Issue Report accordingly if wrong here.

I tried to update Microsoft.DotNet.Runtime.3_1 via winget. There are both versions of this package installed on the system.

On upgrading it only upgrades the x64 package, not the x86 one. Manually telling the bitness with --architecture option won't help either.

Its vice versa, if I install x86 version first and after that trying to install x64 package will result in "already installed package found"

I think winget gets confused, because it cant tell apart x86 and x64 by its ID. If this is the case, then all packages (Microsoft.DotNet.*) are affected by this.

Steps to reproduce

  • Remove all installed packages related to Microsoft.DotNet.Runtime.3_1.
  • Install x86 Microsoft.DotNet.Runtime.3_1 via winget.
  • Install x64 Microsoft.DotNet.Runtime.3_1 via winget.

Actual behavior

winget reports:
"An existing package has already been found. An attempt is made to update the installed package..."

Expected behavior

winget should be able to install x86 and x64 side by side.

For an possibly correct solution, please take a look at (Microsoft.VCRedist.*) packages:

Name                                                 ID                            Version        Quelle
---------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2022 Redistributable (Arm64)    Microsoft.VCRedist.2022.arm64 14.34.31823.3  winget
Microsoft Visual C++ 2019 Redistributable (Arm64)    Microsoft.VCRedist.2019.arm64 14.29.30139.0  winget
Microsoft Visual C++ 2015-2022 Redistributable (x86) Microsoft.VCRedist.2015+.x86  14.38.32919.0  winget
Microsoft Visual C++ 2015-2022 Redistributable (x64) Microsoft.VCRedist.2015+.x64  14.38.32919.0  winget
Microsoft Visual C++ 2013 Redistributable (x86)      Microsoft.VCRedist.2013.x86   12.0.40664.0   winget
Microsoft Visual C++ 2013 Redistributable (x64)      Microsoft.VCRedist.2013.x64   12.0.40664.0   winget
Microsoft Visual C++ 2012 Redistributable (x86)      Microsoft.VCRedist.2012.x86   11.0.61030.0   winget
Microsoft Visual C++ 2012 Redistributable (x64)      Microsoft.VCRedist.2012.x64   11.0.61030.0   winget
Microsoft Visual C++ 2010 x86 Redistributable        Microsoft.VCRedist.2010.x86   10.0.40219     winget
Microsoft Visual C++ 2010 x64 Redistributable        Microsoft.VCRedist.2010.x64   10.0.40219     winget
Microsoft Visual C++ 2008 Redistributable - x86      Microsoft.VCRedist.2008.x86   9.0.30729.6161 winget
Microsoft Visual C++ 2008 Redistributable - x64      Microsoft.VCRedist.2008.x64   9.0.30729.6161 winget
Microsoft Visual C++ 2005 Redistributable            Microsoft.VCRedist.2005.x86   8.0.61001      winget
Microsoft Visual C++ 2005 Redistributable (x64)      Microsoft.VCRedist.2005.x64   8.0.61000      winget

Package architecture is part of package ID

Environment

Windows: Windows.Desktop v10.0.19045.3086
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.20.2201.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

Links
-----------------------------------------------------------------------------------------
Datenschutzerklärung              https://aka.ms/winget-privacy
Lizenzvereinbarung                https://aka.ms/winget-license
Hinweise von Drittanbietern       https://aka.ms/winget-3rdPartyNotice
Startseite                        https://aka.ms/winget
Windows Store-Nutzungsbedingungen https://www.microsoft.com/en-us/storedocs/terms-of-sale

Administratoreinstellung                  Status
-----------------------------------------------------
LocalManifestFiles                        Deaktiviert
BypassCertificatePinningForMicrosoftStore Deaktiviert
InstallerHashOverride                     Deaktiviert
LocalArchiveMalwareScanOverride           Deaktiviert

Screenshots and Logs

No response

@Killom Killom added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Aug 23, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage This work item needs to be triaged by a member of the core team. label Aug 23, 2023
@Trenly
Copy link
Contributor

Trenly commented Aug 23, 2023

@Killom
Copy link
Author

Killom commented Aug 23, 2023

Except, that the mentioned workaround actually does not work - as described above. Thats because for winget both architectures have the same package ID - it is unable to differentiate.

@Trenly
Copy link
Contributor

Trenly commented Aug 23, 2023

Except, that the mentioned workaround actually does not work - as described above.

It seems to work for me.

PS D:\Git\winget-pkgs> winget install Microsoft.DotNet.SDK.6 -a x86
Found Microsoft .NET SDK 6.0 [Microsoft.DotNet.SDK.6] Version 6.0.413
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.413/dotnet-sdk-6.0.413-win-x86.exe

@Killom
Copy link
Author

Killom commented Aug 23, 2023

It seems to work for me.

You can initially tell which bitness to install this way, if no package is installed. Thats correct and working. But now try to make an Side by Side installation this way. Won't be successful, because "package already installed". Upgrading this way will run into the same issue.

@Trenly
Copy link
Contributor

Trenly commented Aug 23, 2023

It seems to work for me.

You can initially tell which bitness to install this way, if no package is installed. Thats correct and working. But now try to make an Side by Side installation this way. Won't be successful, because "package already installed". Upgrading this way will run into the same issue.

You can add the --force flag to force an install instead of switching to the upgrade flow

@BrandonWanHuanSheng
Copy link
Contributor

It look like still not work,

@stephengillie stephengillie removed the Needs-Triage This work item needs to be triaged by a member of the core team. label Aug 24, 2023
@BrandonWanHuanSheng
Copy link
Contributor

BrandonWanHuanSheng commented Nov 4, 2023

I found a particular file which is AppsandFeaturesEntries. The data can be found on the installer.
0 file is InstallerData.
You can load it by rename the file to XML.

@jhennessey
Copy link

I'm running into this issue as well. I'm specifically looking at the Microsoft.DotNet.DesktopRuntime.* and Microsoft.DotNet.AspNetCore.* packages right now. You should be able to install and manage both x86 and x64 versions of these installers but you cannot. Yes, you can use --force to get both architectures installed but it then breaks uninstall as it can't find the package.

As an example:

C:\Users\Administrator>winget install --id Microsoft.DotNet.DesktopRuntime.6 -v 6.0.20 -a x64
Found Microsoft .NET Windows Desktop Runtime 6.0 [Microsoft.DotNet.DesktopRuntime.6] Version 6.0.20
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/6.0.20/windowsdesktop-runtime-6.0.20-win-x64.exe
Successfully verified installer hash
Starting package install...
Successfully installed


C:\Users\Administrator>winget install --id Microsoft.DotNet.DesktopRuntime.6 -v 6.0.20 -a x86 --force
Found Microsoft .NET Windows Desktop Runtime 6.0 [Microsoft.DotNet.DesktopRuntime.6] Version 6.0.20
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dotnetcli.azureedge.net/dotnet/WindowsDesktop/6.0.20/windowsdesktop-runtime-6.0.20-win-x86.exe
Successfully verified installer hash
Starting package install...
Successfully installed

C:\Users\Administrator>winget uninstall --id Microsoft.DotNet.DesktopRuntime.6 -v 6.0.20
No installed package found matching input criteria.

It seems like these should be different packages altogether.

@Killom
Copy link
Author

Killom commented Feb 19, 2024

It seems like these should be different packages altogether.

Thats what I asked for initially. Package ID should be unique for each architecture or else will mess things up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

5 participants