search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.2k stars 1.45k forks source link

try to upgrade vc redist and desktop runtime x86, upgrades x64 instead #2427

Open alisonatwork opened 2 years ago

alisonatwork commented 2 years ago

Brief description of your issue

I've been trying to get all my packages up to date using winget, and for the most part it works, but there are two x86 packages that every time I try to upgrade them, it starts download the (already upgraded) x64 version instead.

It seems that somehow the id for the x64 version has been associated with the name of the x86 version.

I suspect this is similar to the bug #1413 but I am not sure how to fix it.

Steps to reproduce

  1. List upgrades.
winget upgrade

Shows:

Name                                                         Id                                  Version      Available     Source
----------------------------------------------------------------------------------------------------------------------------------
Microsoft Windows Desktop Runtime - 3.1.25 (x86)             Microsoft.DotNet.DesktopRuntime.3_1 3.1.25       3.1.27        winget
Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.30501 Microsoft.VC++2013Redist-x64        12.0.30501.0 12.0.40664.0  winget
  1. Try to upgrade
winget upgrade --verbose-logs "Microsoft Visual C++ 2013 Redistributable (x86) - 12.0.30501"

Instead does the following:

Found Microsoft Visual C++ 2013 Redistributable (x64) [Microsoft.VC++2013Redist-x64] Version 12.0.40664.0
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://download.visualstudio.microsoft.com/download/pr/10912041/cee5d6bca2ddbcd039da727bf4acb48a/vcredist_x64.exe

Expected behavior

I expect the x86 version to be downloaded and upgraded.

Actual behavior

The x64 version is re-downloaded (even though it is already installed) and the x86 version remains in the list of non-upgraded packages.

Environment

Windows Package Manager v1.3.2091
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.317
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2091.0
alisonatwork commented 2 years ago

For reference, I think I have "fixed" the vc redist problem by running winget install Microsoft.VC++2013Redist-x86 and manually uninstalling the old version via Control Panel.

However I don't know if I can fix the Desktop Runtime problem the same way, because winget search "Desktop Runtime" does not show any x86 versions available.

denelon commented 2 years ago

@alisonatwork would you mind trying winget search Microsoft.DotNet?

That should display the SDKs and Runtimes.

You can use "--architecture" to specify the architecture for the install command if it's not defaulting to the proper architecture.

alisonatwork commented 2 years ago

Output of winget search Microsoft.DotNet:

Name                                               Id                                      Version                   Source
----------------------------------------------------------------------------------------------------------------------------
Microsoft .NET Core SDK Uninstall Tool             Microsoft.dotnetUninstallTool           4.80.595                  winget
.NET Framework                                     Microsoft.dotNetFramework               4.8                       winget
Microsoft .NET SDK 7.0 Preview                     Microsoft.DotNet.SDK.Preview            7.0.100-preview.7.22377.5 winget
Microsoft .NET SDK 6.0                             Microsoft.DotNet.SDK.6                  6.0.400                   winget
Microsoft .NET SDK 5.0                             Microsoft.DotNet.SDK.5                  5.0.408                   winget
Microsoft .NET SDK 3.1                             Microsoft.DotNet.SDK.3_1                3.1.422                   winget
Microsoft .NET Runtime 7.0 Preview                 Microsoft.DotNet.Runtime.Preview        7.0.0-preview.7.22375.6   winget
Microsoft .NET Runtime 6.0                         Microsoft.DotNet.Runtime.6              6.0.7                     winget
Microsoft .NET Runtime 5.0                         Microsoft.DotNet.Runtime.5              5.0.17                    winget
Microsoft .NET Runtime 3.1                         Microsoft.DotNet.Runtime.3_1            3.1.28                    winget
Microsoft ASP.NET Core Hosting Bundle 7.0 Preview  Microsoft.DotNet.HostingBundle.Preview  7.0.0-preview.7.22376.6   winget
Microsoft ASP.NET Core Hosting Bundle 6.0          Microsoft.DotNet.HostingBundle.6        6.0.8                     winget
Microsoft ASP.NET Core Hosting Bundle 5.0          Microsoft.DotNet.HostingBundle.5        5.0.17                    winget
Microsoft ASP.NET Core Hosting Bundle 3.1          Microsoft.DotNet.HostingBundle.3_1      3.1.28                    winget
Microsoft .NET Windows Desktop Runtime 7.0 Preview Microsoft.DotNet.DesktopRuntime.Preview 7.0.0-preview.7.22377.1   winget
Microsoft .NET Windows Desktop Runtime 6.0         Microsoft.DotNet.DesktopRuntime.6       6.0.8                     winget
Microsoft .NET Windows Desktop Runtime 5.0         Microsoft.DotNet.DesktopRuntime.5       5.0.17                    winget
Microsoft .NET Windows Desktop Runtime 3.1         Microsoft.DotNet.DesktopRuntime.3_1     3.1.28                    winget
Microsoft ASP.NET Core Runtime 7.0 Preview         Microsoft.DotNet.AspNetCore.Preview     7.0.0-preview.7.22376.6   winget
Microsoft ASP.NET Core Runtime 6.0                 Microsoft.DotNet.AspNetCore.6           6.0.8                     winget
Microsoft ASP.NET Core Runtime 5.0                 Microsoft.DotNet.AspNetCore.5           5.0.17                    winget
Microsoft ASP.NET Core Runtime 3.1                 Microsoft.DotNet.AspNetCore.3_1         3.1.28                    winget

Unfortunately the --architecture flag does not seem to work on upgrade. Instead I tried reinstalling over the top with winget install -a x86 Microsoft.DotNet.DesktopRuntime.3_1. This successfully selected the correct download and installed it.

Now I am running at the latest version (3.1.28) for both x64 and x86 versions. I'm not sure what will happen when the next version comes out. Will I still have to use install and -a x86 to upgrade one of them? If you can't easily reproduce on your end I will let you know next time an upgrade appears.

denelon commented 2 years ago

Related to:

colejohnson66 commented 1 year ago

Not a solution, but I managed to work around this by manually upgrading Microsoft.VCRedist.2015+.x64 (x64, not x86) with winget upgrade <>.

Eutropios commented 1 year ago

Is there a fix for this because this is still affecting me. It attempts to upgrade to the newer version, but the old version still persists.

levicki commented 1 year ago

@denelon Why is this still unsolved?

It seems that Microsoft these days can't even get their download links and versions right, much less anything else.

For example winget offers version 14.38 of runtime which if you try to find and download by going to latest supported downloads and follow the links:

https://aka.ms/vs/17/release/vc_redist.x86.exe
https://aka.ms/vs/17/release/vc_redist.x64.exe

You will get the version 14.36.32532 as the "latest".

Same with Visual Studio 2022 — Visual Studio installer installs 14.36.32532 as the "latest".

So where is winget pulling its "latest" version from? Is it even stable / release version or is it a preview? If it's a preview why is it offered in a production setting?

Danik1601 commented 9 months ago

+1 here

I had the latest version of Visual C++ 2015-2022 Redistributable for x64 architecture which was incorrectly identified as version of x86 (but with x64 id) and updated each time I ran winget upgrade --all until I installed x86 version.

image