Ryzen fails due to failed version comparison

[denelon]

@denelon thank you for getting back to me.
I can confirm that CTRL+C now kills the download.

Since I've re-installed my Windows, a lot of the checks are uncheckable for me now.
Other things that I'm noticing now:

Ryzen fails due to failed version comparison:

Discord fails due to it still running:

13008> 2021-10-02 08:32:32> Program: Starting Squirrel Updater: --install . /s
13008> 2021-10-02 08:32:32> Program: Starting install, writing to C:\Users\maste\AppData\Local\SquirrelTemp
13008> 2021-10-02 08:32:32> Program: About to install to: C:\Users\maste\AppData\Local\Discord
13008> 2021-10-02 08:32:32> Program: Install path C:\Users\maste\AppData\Local\Discord already exists, burning it to the ground
13008> 2021-10-02 08:32:32> IEnableLogger: Failed to remove existing directory on full install, is the app still running???: System.IO.IOException: Access to the path 'C:\Users\maste\AppData\Local\Discord' is denied.

Unity is still being installed as a separate version when doing upgrade --all. Suggestion: Remove the upgrade option from Winget for this application.

Originally posted by @Master-Guy in microsoft/winget-cli#1009 (comment)

[Trenly]

@denelon Any suggestions on what specifically should be done here? To me it seems as though these are either non-issues, or are being tracked elsewhere. Reading through it, here is what I see:

Ryzen Failed Version Comparison

This looks like an issue with Ryzen to me, not with winget. The only other thing I can think it could be is an incompatibility between installer types, but after few minutes on google I wasn't able to find anything indicating this would be the case

Discord fails due to it's still running

Again, not sure this is a winget issue. If anything, I would imagine it would be clarified with ExpectedReturnCodes once the 1.1.0 schema is released?

Unity being installed as a separate version

Unity has now been split into separate packages, so this should be less of an issue. Once pinning is completed, it will be no issue at all.

[Master-Guy]

@Trenly from an end-user perspective (and please do wait for feedback from denelon):

• Ryzen: If the installer is not compatible with winget, then should it even be included in winget library?
• Discord: I would suggest/hope that winget would have an optional "kill process tree with this name before installing" option in the configuration files.
• Unity: I hope that works, please let me know when it is ready to test, and I'll kick off the installer on my machine.

[Trenly]

• Ryzen: If the installer is not compatible with winget, then should it even be included in winget library?

winget install AMD.RyzenMaster works fine for me. I tested on a VM and in sandbox. I also couldn't find anywhere to install the version of Ryzen Master mentioned in the original post to test the upgrade, indicating this would likely be an edge case. To me it doesn't seem like an issue where the installer isn't compatible with winget, but it seems like an issue with the specific machine or installation that originally experienced the issue.

• Discord: I would suggest/hope that winget would have an optional "kill process tree with this name before installing" option in the configuration files.

This has been discussed lightly in other topics. The last I heard, applications wouldn't be killed automatically and would require users to terminate them. This is because winget upgrade --all can be run in the background, and if winget were to suddenly terminate something that a user was actively using, perhaps not realizing it was part of the upgrade, it could lead to an even worse user experience. This also is the case for if the upgrade is a scheduled task. If someone was working on something important and winget suddenly terminated the app forcefully, then the work could potentially be lost.

• Unity: I hope that works, please let me know when it is ready to test, and I'll kick off the installer on my machine.

The changes have been in the repo for a few days. The packages from the winget source were split into UnityTechnologies.Unity.2020 and UnityTechnologies.Unity.2021 and should already be live

[denelon]

@Master-Guy winget upgrade --all is the most complex feature in the Windows Package Manager due to the sheer number of edge cases based on how many different upgrade paths could exist. I've been fielding and cataloging the issues for quite a while now. I've kept this issue open since it is so detailed and includes several of the key issues we're working on, and it's not an "upgrade --all" scenario. @Trenly is correct as far as I can tell with his assessments.

The MSIX package format on Windows is the most deterministic packaging format in terms of error messages, and behavior. All the other formats including MSI still have rough edges (some error codes have multiple reasons why they are thrown). When we encounter EXE based installers, there is no standard behavior for error codes or exit codes. In many cases, it takes hundreds of users to encounter a problem before our sampling of telemetry data (not all users leave telemetry enabled) starts to build a picture we can act on.

We've been working through classes of problems we can fix or at least report and inform users on. This is a very exciting and challenging piece of technology to work on. I wish we could determine the problems and fix them faster, but everything we try could cause negative experiences elsewhere. Sometimes the problem with the upgrade scenario is a flag or switch the installer needs to perform an upgrade rather than throw an error. We just had the Visual Studio package adjusted in the last week or so. Maybe something like that would help Ryzen Master. Discord does seem to keep processes running in the background, so the installer when executed silently doesn't inform the user that the program is running and give an option to shut it down. One of our goals is to enable the winget upgrade -all to be able to silently just upgrade everything. We've been trying to determine the best way from a user experience perspective to handle this, and to detect when certain types of failures might occur. Hopefully the issues with Unity have been resolved with changes to the manifest.

I do want to let you know I truly appreciate the time you took to report the issue. Many users don't take the time to help us make the product better. It's also very likely at this point since we're generally available on Windows 10 (1809+) and Windows 11 that most users don't even know the product is open source, and how to contact us.

I try to keep the "first report" for a bug as the open work item we track to resolution. In some cases, multiple different issues are reported, and that makes things a bit more complicated. Out of respect for the community, I try to be as transparent as possible with what is broken and how we're progressing.

[Trenly]

I appreciate the detailed update!

[Master-Guy]

Same here, I love how this community is giving all the feedback, and working together to make this awesome product a reality!

By now I've moved to Windows 11, and on my PC I have installed Unity Hub 2.4.5, and within that is an installation of Unity 2021.1.28f1. Winget correctly identifies Unity Hub being version 2.4.5, and correctly identified Unity 2021.1.28f1 installed, but also reported Unity 2021.1.23f1. It seems that when I did my Windows 11 installation (October 6th), followed by a winget import, it did install the Unity 2021.1.23f1 that was in my export list, but it did not install Unity Hub.

Running winget upgrade now doesn't list any of the Unity Editor applications, which should be correct. However, when running winget export, it tells me:

Installed version of package is not available from any source: UnityTechnologies.Unity.2020 2021.1.23f1
Installed version of package is not available from any source: UnityTechnologies.Unity.2020 2021.1.28f1

Not sure if this is a side-effect of splitting out the different options. When running winget search Unity, it lists two versions of the editor, both of which are not listed in the Unity Hub installer. It also shows a Unity and a Unity 2021, where I would expect a consistant naming.

Unity                                 UnityTechnologies.Unity.2020                  2020.3.19f1                        winget
Unity Hub                             UnityTechnologies.UnityHub                    2.4.5               Tag: unity     winget
Unity 2021                            UnityTechnologies.Unity.2021                  2021.2.0            Tag: unity     winget

TLDR:

1. Winget helped me identify a lost installation of Unity Editor on my C drive, while all my other installs are on D, E or F.
2. Winget now (correctly) doesn't install a new Unity Editor, but I'm not sure if it's because of the lower version number, or because of changes that were made.

[Trenly]

Thank you for taking the time to report this issue. In the amount of time the issue has been open, there have been several updates to the WinGet CLI which may have helped mitigate some of these concerns. I encourage you to try out the latest version of the CLI and see if your problem still persists.

If additional problems persist, it would be extremely helpful if a new issue could be opened. Thanks!

Close with reason: Stale;