microsoft / winget-create

The Windows Package Manager Manifest Creator command-line tool (aka wingetcreate)
MIT License
472 stars 83 forks source link

`wingetcreate update` / `wingetcreate update -i` Installer version problem #503

Open ghost opened 6 months ago

ghost commented 6 months ago

Brief description of your issue

wingetcreate fails to identify installer new version and replaces only hash in old version manifests.

Steps to reproduce

wingetcreate update WHONET.2023 New version number is 23.13.8 but wingetcreate updated installer hash in old version 23.12.14 manifest. Screenshot (12)

Expected behavior

It should detect new version number from installer and detect that package is using vanity url. So it should replace old version with new version manifest.

Actual behavior

PS C:\Users\drsht> wingetcreate update WHONET.2023
Retrieving latest manifest for WHONET.2023
Downloading and parsing: https://whonet.org/WHONET2023-Setup-x86.exe...
Downloading and parsing: https://whonet.org/WHONET2023-Setup-x64.exe...

The architecture detected from the binary might be different than what is specified in the installer URL for the following installer(s):
Using architecture detected from URL (X64), overriding architecture detected from binary (X86)
https://whonet.org/WHONET2023-Setup-x64.exe

Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
DefaultLocale: en-US
ManifestType: version
ManifestVersion: 1.5.0

Installer manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
InstallerType: burn
Installers:
- Architecture: x86
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x86.exe
  InstallerSha256: AA35364ABEE7B1229533E781173733AEE628D1293557C8688F4225F56958BCBA
- Architecture: x64
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x64.exe
  InstallerSha256: 0B8C70A5B148C476A83A505C74D18EA9A7C7F34F3BAE108CBB9FC1725248A9F6
ManifestType: installer
ManifestVersion: 1.5.0

Default locale manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
PackageLocale: en-US
Publisher: Brigham and Women's Hospital
PublisherUrl: https://whonet.org
PublisherSupportUrl: https://whonet.org/contact.html
Author: Brigham and Women's Hospital
PackageName: WHONET 2023
PackageUrl: https://whonet.org/software.html
License: Freeware
Copyright: Copyright (c) Brigham and Women's Hospital. All rights reserved.
ShortDescription: WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance.
Description: |-
  WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance developed and supported by the WHO Collaborating Centre for Surveillance of Antimicrobial Resistance at the Brigham and Women's Hospital in Boston, Massachusetts.
  WHONET, available in 44 languages, supports local, national, regional, and global surveillance efforts in over 2,300 hospital, public health, animal health, and food laboratories in over 130 countries worldwide.
  WHONET 2023 is a modernized and expanded version of WHONET 5.6. This version supports 44 languages and includes new features for exporting to the WHO GLASS data structure.
  It includes support for CLSI 2023 M100, M45, M60, M61, as well as EUCAST 2023 bacterial breakpoints. Also included are the most recent CLSI VET01, VET03/04, and VET06 breakpoints.
Moniker: WHONET
Tags:
- Microbiology
- Laboratory
- Bacteriology
- BacLink
- AMR
- Antibiotics
- Resistance
- CLSI
- EUCAST
- WHO
- GLASS
ManifestType: defaultLocale
ManifestVersion: 1.5.0

Manifest saved to %USERPROFILE%\manifests\w\WHONET\2023\23.12.14

Manifest validation succeeded: True

wingetcreate update WHONET.2023 -i

Generating a preview of your manifests...
Version manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.version.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
DefaultLocale: en-US
ManifestType: version
ManifestVersion: 1.5.0

Installer manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.installer.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
InstallerType: burn
Installers:
- Architecture: x86
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x86.exe
  InstallerSha256: AA35364ABEE7B1229533E781173733AEE628D1293557C8688F4225F56958BCBA
- Architecture: x64
  InstallerUrl: https://whonet.org/WHONET2023-Setup-x64.exe
  InstallerSha256: 0B8C70A5B148C476A83A505C74D18EA9A7C7F34F3BAE108CBB9FC1725248A9F6
ManifestType: installer
ManifestVersion: 1.5.0

Default locale manifest preview:
# Created using wingetcreate 1.5.7.0
# yaml-language-server: $schema=https://aka.ms/winget-manifest.defaultLocale.1.5.0.schema.json

PackageIdentifier: WHONET.2023
PackageVersion: 23.12.14
PackageLocale: en-US
Publisher: Brigham and Women's Hospital
PublisherUrl: https://whonet.org
PublisherSupportUrl: https://whonet.org/contact.html
Author: Brigham and Women's Hospital
PackageName: WHONET 2023
PackageUrl: https://whonet.org/software.html
License: Freeware
Copyright: Copyright (c) Brigham and Women's Hospital. All rights reserved.
ShortDescription: WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance.
Description: |-
  WHONET is a free desktop Windows application for the management and analysis of microbiology laboratory data with a particular focus on antimicrobial resistance surveillance developed and supported by the WHO Collaborating Centre for Surveillance of Antimicrobial Resistance at the Brigham and Women's Hospital in Boston, Massachusetts.
  WHONET, available in 44 languages, supports local, national, regional, and global surveillance efforts in over 2,300 hospital, public health, animal health, and food laboratories in over 130 countries worldwide.
  WHONET 2023 is a modernized and expanded version of WHONET 5.6. This version supports 44 languages and includes new features for exporting to the WHO GLASS data structure.
  It includes support for CLSI 2023 M100, M45, M60, M61, as well as EUCAST 2023 bacterial breakpoints. Also included are the most recent CLSI VET01, VET03/04, and VET06 breakpoints.
Moniker: WHONET
Tags:
- Microbiology
- Laboratory
- Bacteriology
- BacLink
- AMR
- Antibiotics
- Resistance
- CLSI
- EUCAST
- WHO
- GLASS
ReleaseNotesUrl: https://whonet.org/WHONET-ReleaseNotes.html
ManifestType: defaultLocale
ManifestVersion: 1.5.0

Manifest saved to %USERPROFILE%\manifests\w\WHONET\2023\23.12.14

Manifest validation succeeded: True

Screenshot (10)

Environment

PS C:\Users\drsht> wingetcreate --help
Windows Package Manager Manifest Creator v1.5.7.0
PS C:\Users\drsht> winget --info
Windows Package Manager v1.6.3482
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.2861
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.3482.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
Installer Downloads                %USERPROFILE%\Downloads

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

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Enabled
LocalArchiveMalwareScanOverride           Disabled
github-actions[bot] commented 6 months ago

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

Closed similar issues:

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

ghost commented 6 months ago

It does automatically parse it if you run ~wingetupdate -i~ wingetcreate update -i, not that that helps.

https://github.com/microsoft/winget-create/issues/177 comment mentions that -i should detect version from installer, but it also doesn't do that.

mdanish-kh commented 5 months ago

I think we can detect the "correct" version from the installer file with high confidence only if it's an MSI or an MSIX. The example you showed is an .exe, which can have all sorts of different behaviors depending on how the installer is made. One way for .exe is to look at the FileVersion / ProductVersion file property (that @wingetbot uses in its automation). The problem with that approach is that not all publishers set this value and even if they do, it does not match the actual version written to Registry / Apps&Features, resulting in a lot of false matches.

If wingetcreate auto-fills a version for a user, I think it should be the one that's the actual DisplayVersion written to Registry, and for that I think the implementation should first target MSIX and MSIs, and then optionally see if something can be done for .exe's.

The wingetcreate new command already fetches the version for MSIX's, so as a first step, we can look to replicate that behavior for the update command

ghost commented 5 months ago

I think we can detect the "correct" version from the installer file with high confidence only if it's an MSI or an MSIX. The example you showed is an .exe, which can have all sorts of different behaviors depending on how the installer is made. One way for .exe is to look at the FileVersion / ProductVersion file property (that @wingetbot uses in its automation). The problem with that approach is that not all publishers set this value and even if they do, it does not match the actual version written to Registry / Apps&Features, resulting in a lot of false matches.

If wingetcreate auto-fills a version for a user, I think it should be the one that's the actual DisplayVersion written to Registry, and for that I think the implementation should first target MSIX and MSIs, and then optionally see if something can be done for .exe's.

The wingetcreate new command already fetches the version for MSIX's, so as a first step, we can look to replicate that behavior for the update command

wingetcreate new correctly identified version for same exe when I initially submitted the package, but during wingetcreate update it is not detected. That is what I am saying.

ghost commented 5 months ago

wingetcreate update already downloads and parses the installer, so why can't it check for the same like wingetcreate new. Using -i with command should show a similar flow with version number suggested which is detected from installer. In my example, the package has correct display version in registry/app&features with each new version.

Screenshot 2024-01-17 202146