Updateproblem: Visual Studio 2015-2022 Redistributable (x64) – liegt Ursache bei winget oder bei Microsoft?

Winget zeigt Update-Fehler mit der Visual C++ Studio 2015-2022 Redistributable (x64) sowie veralteter Inhalte im zugehörigen Microsoft Learn Artikel auf. Ein Gastbeitrag von Jo Arnold

Die teilweise zahllos installierten Redistributable-Versionsnummern, die mit diverser Software auf den Rechner kommen, durch eine Installation der jeweils neuesten Version von 2005, 2008, 2010, 2012 sowie der 2015-2022 zu ersetzen, deckte letztlich einen Fehler in Verbindung von Microsoft Visual C++ Studio 2015-2022 Redistributable (x64) mit winget und den veralteteten Informationen nicht nur zur Microsoft Visual C++ 2008 Redistributable unter Microoft Learn auf. Ein Erfahrungsbericht. Links am Seitenende.

Microsoft Learn

Unter Microsoft Learn gibt es eine eigentlich ganz sinnvolle Seite (Link am Seitenende), die für alle Versionen eine Übersicht zu den (vorgeblich) aktuellsten fehlerfreien Updates und den Downloads bereitstellt. Von Version 2005 bis 2022 installierte ich testweise jeweils die neuesten Varianten für (x64) als auch (x86). ARM64 wurde nicht getestet.

Die Verwendung der Downloads von Microsoft Learn ersetzten tatsächlich vollständig die diversen Untervarianten derselben Visual Studio Versionen. So ersichtlich für (x64) und (x86) in den Listen von CPL Programme und Features als auch in der abgespeckten und nicht sonderlich praktischen Darstellung der Apps und Features. Die nach dem Update durchgeführten Tests von bereits vorher installierter Software, die jeweils ihre eigenen Redistributable-Unterversionsnummern mitbrachten, liefen allesamt fehlerfrei. Installierte ich im Anschluss eine weitere Software von der ich wusste, dass diese ansonsten immer eine veraltete Redistributable-Unterversionsnummer installiert hat, so fand dies nun nicht mehr statt. Alles läuft wie erwartet und gewünscht.

Downloads und Infos auf Microsoft Learn nicht aktuell

Microsoft Learn gibt an, dass für VC++ Visual Studio 2008 die 9.0.30729.5677 (x64) + (x86) die aktuellste Version ist. Winget zeigte nach der Installation aber unmittelbar Version 9.0.30729.6161 als Update an (Links am Seitenende). Update per winget läuft dann aber fehlerfrei. Seit einiger Zeit betrifft das auch die Version 2015-2022 von Microsoft Learn. Fazit: Microsoft Learn ist hier nicht aktallisiert worden.

Update-Fehler mit Visual Studio 2015-2022 Redistributable (x64)

Auch die Redistributable-Version 2015-2022 installierte ich in den Varianten (x64) und (x86), die wie in Programme und Features als auch unter Apps und Features mit der erwartbaren Versionsnummer und der Angabe zu (x64) und (x86) erscheinen. Selbst winget list führte im Output die Microsoft Visual C++ 2015-2022 Redist… zweimal auf. Soweit korrekt und ich schenkte den Details in winget bis vor wenigen Wochen keine weitere Beachtung.

Seit geraumer Zeit bietet winget für die beiden 2015-2022 Redistributable ein Update von 14.38 auf die v.14.40.33617.1 an. Nach einiger Zeit machte ich zuerst einen Abgleich bei Microsoft Learn, die aber nach wie vor – sagen wir – die alte Version 14.38 beschreibt und auch der Download bringt dort bis dato nur die alten Installationsdateien. Die Signatur der 14.40 Installer trägt den Zeitstempel vom 18. Februar 2024. ARM64 wurde nicht getestet. Fazit: Microsoft Learn ist hier nicht aktualisiert worden.

Mit „winget show Microsoft.VCRedist.2015+.x64″ und Microsoft.VCRedist.2015+.x86“ wird der neue Downloadlink angezeigt (Link am Seitenende). Erst per winget und später per manuellem Download installierte ich die neueste v.14.40. Warum das mehrfach geschah, folgt jetzt.

Nach dem Update war die v.14.40 unter Programme und Features als auch unter Apps und Features korrekt mit (x64) sowie (x86) gelistet. Mit winget sieht es aber völlig anders aus. Denn egal ob nun die alte (x64) v.14.38 aus Microsoft Learn oder die neue (x64) über den Downloadlink von winget installiert werden: winget sieht beide (x64) „teilweise“ nur als (x86).

Wie man merkt, so ist das schnell zu übersehen. Erst wenn man mit winget die (x64) updatet. Somit also winget das Update durchführt, dabei aber das Update für die (x86) zieht und danach die Software immer noch in winget nach der neuen Version durstet, fällt evtl. auf, dass hier etwas nicht stimmt.

Manuell installiert sind (x64) + (x86) v.14.38.33135.0 (source: Microsoft Learn)

• winget list
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.38.33135.0
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.38.33135.0
• Beide deinstalliert, danach nur (x64) neu installiert
• winget list
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.38.33135.0

In beiden Varianten zeigt winget für die (x64) als ID die Variante (x86) an.

Manuell installiert sind (x64) + (x86) v.14.40.33617.1 (source: winget Links)

• winget list
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.40.33617.1
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.40.33617.1

Beide deinstalliert, danach nur (x64) neu installiert

• winget list
• Microsoft Visual C++ 2015-2022 Microsoft.VCRedist.2015+.x86 14.40.33617.1

In beiden Varianten zeigt winget für die (x64) als ID die Variante (x86) an.

Zieht man das Fenster der cmd breiter, dann sind auch die Spalten breiter, das Ergebnis wird offensichtlicher:

• winget list
• Microsoft Visual C++ 2015-2022 Redistributable (x64) Microsoft.VCRedist.2015+.x86 14.40.33617.1

Dem Namen der (x64) wird also als Paket-ID die Microsoft.VCRedist.2015+.x86 zugeordnet.

Auswirkung:
Installiert man mit winget bei der (x64) das angezeigte Update von 14.38 auf 14.40, dann läuft das Setup in winget zwar irgendwie erfolgreich durch, es installiert aber das Update für die (x86), sofern die (x86) neben der (x64) überhaupt vorhanden ist. Daher ist nach dem Update der falsch dargestellten (x86)-ID die Software mit dem Namen des (x64) natürlich nicht auf dem aktuellen Stand.

• Das Problem existiert mindestens seit der Version 14.38.33135.0 und das auch, bevor es über winget die v.14.40 gab.
• Die Abfrage auf den Namen bezogen zeigt mit winget die richtige Zuordnung zur (x64):
• winget show „Microsoft Visual C++ 2015-2022 Redistributable (x64)

So wie ich es bisher umfasse, so laufen ohne weiteres Zutun die Updates über die ID, weshalb das gezogene Update durch die falsch zugeordnete ID wirkungslos ist. Wer also nachweislich ein (x64) von vor v.14.40 updaten will, der macht das Update z. B. in winget manuell per abgeänderter ID Microsoft.VCRedist.2015+.x64 und das funktioniert dann auch.

• winget update Microsoft.VCRedist.2015+.x64

winget show Microsoft.VCRedist.2015+.x64 zeigt den aktuellen Downloadlink an. Per Browser kann dann ein manueller Download initiiert werden. Praktisch, da man dann auch die Source für weitere Rechner hat. Aber keiner der Weg behebt die Problematik, dass auch die (x64) v.14.40 erneut der falschen ID mit Microsoft.VCRedist.2015+.x86 zugeordnet wird. Das verursacht bei künftigen Updates denselben Fehler.

Ich befasse mich zwischendurch seit einiger Zeit mit dem Thema. Auf Github gibt es bereits mindestens einen gemeldeten Issue zum Thema. Es scheint, dass hier winget die Verantwortung auf Microsoft schiebt. Es erweckt aber auch den Eindruck, dass man auf Seiten von winget das nicht überprüft hat und daher auch nicht belegen kann, dass die falsche ID-Zuordnung eben nicht durch winget erzeugt wird.

Vielleicht hilft dieser Artikel, dass das leidliche Problem endlich gehört und beseitigt wird.

Links (Stand 2024-03-29)

• Github – winget Issue
• Microsoft Learn (teilweise veraltet) Microsoft Visual C++ Redistributable latest supported downloads
• Installer Downloads:
• 2008 – 9.0.30729.6161 (winget)
• Visual Studio 2008 redist – 9.0.30729.6161 (x64)
• Visual Studio 2008 redist – 9.0.30729.6161 (x86)
• 2015-2022 v.14.38.33135.0 (Microsoft Learn)
• Visual C++ 2015-2022 redist – 14.38.33135.0 (x64)
• Visual C++ 2015-2022 redist – 14.38.33135.0 (x86)
• v.14.40.33617.1 (winget)
• Visual C++ 2015-2022 redist – 14.40.33617.1 (x64)
• Visual C++ 2015-2022 redist – 14.40.33617.1 (x86)