[Package Issue]: AnyDeskSoftwareGmbH.AnyDesk

[trparky]

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

Other

Brief description of your issue

Winget seems to be parsing the version information from the Windows Registry in an incorrect way.

Steps to reproduce

1. Execute "winget upgrade".
2. Take note how winget seems to pull the version from the Registry with a carrot (I think it's a carrot) on the front. See screen shot below.

Actual behavior

See steps to reproduce and screen shot.

Expected behavior

Pull the version from the Registry without the carrot. (I think it's a carrot)

Environment

PS C:\Users\trpar> winget --info
Windows Package Manager (Preview) v1.4.2011-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.832
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.2011.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

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

Screenshots and Logs

[JohnMcPMS]

This looks like a bad manifest to me. Looking at the history, we would have to ask @OfficialEsco if they remember why they made the version start with "ad" in #14259.

I just installed the latest on a sandbox and the DisplayVersion is "7.0.13"

The website lists it under the download button as "v7.0.13 (3.8 MB)", no "ad" involved. I don't see any reason why we should want to use a non-standard, non-sortable package version like this. It should be changed to be PackageVersion: 7.0.13, which would resolve the issue you are seeing.

[OfficialEsco]

The EXE package which most people have installed contains ad

IF we use 7.0.13 instead of ad 7.0.13 all the exe users will be in a constant upgrade loop.

[denelon]

The "<" symbol means we evaluated the version, and it was less than one of the manifests we have in range.

[JohnMcPMS]

I was going to suggest that DisplayVersion solves this, but it doesn't really work as coded for joining two disparate versions like the exe/msi here. The only thought that comes to mind is improving the version parsing logic here to better ignore the leading "ad".

DisplayVersion (as coded) is always going to create a range that overlaps one or the other of lower values, making it never upgrade.

As far as the version parsing goes, I'm thinking that if there are leading non-decimal characters followed by decimal characters in the first version part, we can ignore them? So ad 7.0.13 == 7.0.13 and v1.2.3 == 1.2.3. foo1 == bar1 would also be true, but 1.foo2 != 1.bar2.

AnyDesk, with only the one version at a time, isn't actually impacted by this much (until "ad 10.0.0" doesn't sort higher than "ad 9.9.9"). And this issue is more about the confusing < VERSION which was intended to indicate "less than VERSION". But improving the baseline version parsing would remove the need for using the "ad" here (or allow it, depending on preference). And it would certainly remove the need to use DisplayVersion mapping.

@OfficialEsco and @jedieaston , you have more experience with the plethora of version numbers out there. Do you see any issue with my suggestion above? Any improvement? We obviously have to be careful not to disrupt the existing behavior, but I don't really see a problem affecting versions that don't start with numbers.

[OfficialEsco]

AnyDesk exe is the only package which have this stupid Version schema, there was actually a period where we had AnyDesk.AnyDesk.MSI and AnyDesk.AnyDesk.EXE to work around this issue..

I don't see any issues in doing that, that could maybe also resolve the v<VersionNumber> inconsistency too

[jedieaston]

This also sounds good to me.

[trparky]

Any update on this issue?

[denelon]

It's a relatively low priority ask at this point as there are very few 👍 on the issue, and relatively few packages with this problem impacting upgrade.

[R-Adrian]

(maybe this will increase the priority?) AnyDesk 7.0.14 was released recently to fix another security vulnerability (the changelog doesn't mention any CVE for it, or other details yet) but winget still tries to "upgrade" from 7.0.14 to the old 7.0.13.

side note: Firefox Developer edition also seems affected by a similar wrong version detection

[khewweifeng]

Hi, I also facing issue with anydesk installation

Installer hash does not match; this cannot be overridden when running as admin

[OfficialEsco]

Currently blocked in validation for unknown pipeline issue reasons

• New version: AnyDeskSoftwareGmbH.AnyDesk version 7.1.6 #86858

[NJT145]

The hash must to be updated. But there is an other problem: There is a lack of separation of AnyDesk.exe and AnyDesk.msi versions. For example, while I use installation by "AnyDesk.exe", winget list Anydesk gives Id=AnyDeskSoftwareGmbH.AnyDesk and Version=> 7.1.6.
You can use exe or msi to install it. Take a look at here.
Maybe it is better to separate those versions like AnyDeskSoftwareGmbH.AnyDesk.exe and AnyDeskSoftwareGmbH.AnyDesk.msi .

[NJT145]

A simple note:
You can install AnyDesk.exe version of this program by using this simple powershell script:

Invoke-Command -ScriptBlock {
    $InstallDir = “C:\Program Files (x86)\AnyDesk”;
    $TempInstall = "$env:temp\AnyDesk.exe";
    $url = "https://download.anydesk.com/AnyDesk.exe";
    Invoke-WebRequest -Uri $url -OutFile $TempInstall;
    Invoke-Command -ScriptBlock { CMD /C "$TempInstall --install $InstallDir --start-with-win --create-shortcuts --create-desktop-icon --update-manually" };
    Remove-Item -Path $TempInstall }

Check the official documentation for available parameters.

[OfficialEsco]

Separating the package causes a bigger issue where both the MSI and EXE matches, the only difference is the stupid version name of the EXE which is ad <version>

[NJT145]

The only difference is NOT the version name. For example, msi version installs at "C:\Program Files (x86)\AnyDeskMSI" while exe version installs at "C:\Program Files (x86)\AnyDesk". In installation folder, the msiversion adds "MSI" at the end of name ("AnyDeskMSI.exe"). As a result, it would be better to separate "AnyDesk.exe" version from regular msi version.
You can create a new package for exe version with id=AnyDeskSoftwareGmbH.AnyDesk.exe to solve any conflict issues for that.
I also created a powershell script for exe version's installation. You can use this script:

Invoke-Command -ScriptBlock {
    $InstallDir = “C:\Program Files (x86)\AnyDesk”;
    $TempInstall = "$env:temp\AnyDesk.exe";
    $url = "https://download.anydesk.com/AnyDesk.exe";
    Invoke-WebRequest -Uri $url -OutFile $TempInstall;
    [string[]] $argList = @("--install $InstallDir", "--start-with-win", "--create-shortcuts", "--create-desktop-icon", "--remove-first", "--update-manually");
    Start-Process -FilePath $TempInstall -ArgumentList $argList -Wait;
    Remove-Item -Path $TempInstall }

[NJT145]

I checked the manifest and see that exe version is already in it.
As a result, we need to check if winget upgrade have any conflict with that.
And, it can be better to use exe version as default, because of version number issue on msi version. (exe version shows version 7.1.7)

[OfficialEsco]

Just retested the exe, and its still broken

[NJT145]

when I use same command at powershell, version number is correct. So, what can cause this issue?
My powershell code is this:
Invoke-Command -ScriptBlock { $InstallDir = "C:\Progra~2\AnyDesk"; if (-not (Test-Path -Path $InstallDir)) {$InstallDir = “C:\Progra~1\AnyDesk”}; $TempInstall = "$env:temp\AnyDesk.exe"; $url = "https://download.anydesk.com/AnyDesk.exe"; Invoke-WebRequest -Uri $url -OutFile $TempInstall; [string[]] $argList = @("--install $InstallDir", "--update-auto", "--create-desktop-icon", "--create-shortcuts"); Start-Process -FilePath $TempInstall -ArgumentList $argList -Wait; Remove-Item -Path $TempInstall }
What is the difference between this and the winget's install of exe?
Any ideas?

[NJT145]

when I use same command at powershell, version number is correct. So, what can cause this issue?
My powershell code is this:
Invoke-Command -ScriptBlock { $InstallDir = "C:\Progra~2\AnyDesk"; if (-not (Test-Path -Path $InstallDir)) {$InstallDir = “C:\Progra~1\AnyDesk”}; $TempInstall = "$env:temp\AnyDesk.exe"; $url = "https://download.anydesk.com/AnyDesk.exe"; Invoke-WebRequest -Uri $url -OutFile $TempInstall; [string[]] $argList = @("--install $InstallDir", "--update-auto", "--create-desktop-icon", "--create-shortcuts"); Start-Process -FilePath $TempInstall -ArgumentList $argList -Wait; Remove-Item -Path $TempInstall }
What is the difference between this and the winget's install of exe?
Any ideas?

[OfficialEsco]

Tested your script, same version number.

[NJT145]

I see it now. It is not reflected to winget list results, so I didn't see it before...
So, we need to wait untill this issue solved in order to switch to exe, than okay.

[NJT145]

I figured out a small difference between exe version and msi version:
In order to backup your workspace, you need to backup .trace and .conf files on C:\ProgramData\AnyDesk . Be careful about these:

exe <-> msi
C:\ProgramData\AnyDesk\ad_svc.trace <-> C:\ProgramData\AnyDesk\ad_msi\ad_msi_svc.trace
C:\ProgramData\AnyDesk\service.conf <-> C:\ProgramData\AnyDesk\ad_msi\service.conf
C:\ProgramData\AnyDesk\system.conf <-> C:\ProgramData\AnyDesk\ad_msi\system.conf

You can use same config files on both, just don't forget to change .trace filename accordingly.

[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;