Open ghost opened 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!
wingetcreate update
does not parse and detect version (#177), similarity score: 0.84wingetcreate update
different InstallerType
(#75), similarity score: 0.90wingetcreate new
detected installertype that fails (#26), similarity score: 0.83Note: You can give me feedback by thumbs upping or thumbs downing this comment.
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.
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
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 theFileVersion
/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 theupdate
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.
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.
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.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
wingetcreate update WHONET.2023 -i
Environment