`wingetcreate update` / `wingetcreate update -i` Installer version problem about winget-create HOT 5 OPEN

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.

from winget-create.

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:

• wingetcreate update does not parse and detect version (#177), similarity score: 0.84

Closed similar issues:

• wingetcreate update different InstallerType (#75), similarity score: 0.90
• Can't install wingetcreate (#325), similarity score: 0.83
• wingetcreate new detected installertype that fails (#26), similarity score: 0.83
• wingetcreate update fails while there is a version number in the zip archive (#414), similarity score: 0.82

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

from winget-create.

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

#177 comment mentions that -i should detect version from installer, but it also doesn't do that.

from winget-create.

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

from winget-create.

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.

from winget-create.