Product version not updated after application update

[janih78]

Squirrel 1.5.2 is working.
Squirrel 1.7.8 is not working.

Application initial install sets product version properly in registry (or Control Panel -> Uninstall Program), but the version is not updated while updating the application.

So, if you open RegEdit and check the key "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall<appname>\DisplayVersion" before and after application update, you can see that it doesn't change at all.

[Thieum]

@janih78 Are you still experiencing this issue with the latest version of Squirrel?

[simader]

Yes, I still have that problem. Any fix for this?

[rollingmoai]

Updates on this? This is causing issues in Winget, where it reads the outdated version from the product version:

• Upgrade does not work properly on auto-updating apps microsoft/winget-pkgs#15661

[anaisbetts]

I think that WinGet should probably not rely on this registry setting and instead should special-case Squirrel apps. I know that sounds Dum but even if we fixed this today, many many many apps are still gonna use old versions of Squirrel.

The canonical way to determine the latest version for a Squirrel app is:

1. Find the root installation directory (i.e. %LocalAppData%\TheAppName)
2. List all directories that start with app-
3. Strip the app- prefix, and take the highest-by-Semver v1 number you find

Also, why would WinGet need to manage updates for an auto-updating application? afaik all it needs to do is manage install/uninstall

[rollingmoai]

Also, why would WinGet need to manage updates for an auto-updating application? afaik all it needs to do is manage install/uninstall

Package pinning has just been implemented in Winget, so you can now ignore updates for specific applications. But I don't think Squirrel apps should be special-cased just because of a "bug." Other auto-updating apps work well with Winget; that should be the case with Squirrel too.

but even if we fixed this today, many many many apps are still gonna use old versions of Squirrel.

Idealistically, taking the issue upstream with the publisher would be the best course of action.

[anaisbetts]

Package pinning has just been implemented in Winget, so you can now ignore updates for specific applications

This won't actually work though, because Squirrel will update the app anyways

[denelon]

WinGet has some extra work to do for squirrel installers:

• Add Squirrel installertype microsoft/winget-cli#372
• Support installers that close the install process and launch a new process for install microsoft/winget-cli#418
• Support special behavior for upgrading Squirrel applications microsoft/winget-cli#1748

[denelon]

The comment on pinning is intended to essentially ignore pinned packages in the winget upgrade --all flow. We're aware applications will upgrade themselves regardless of the pinning status in WinGet.

[robmen]

The version should be updated to match the version installed by Squirrel.

[denelon]

WinGet uses the "displayVersion" in the registry which also drives the version displayed in Windows Apps & Features to do the version comparison to evaluate if a new version is available. It's the only reliable mechanism for us to keep things in sync and not cause user confusion.

We do support marketing versions for products via the "packageVersion" attribute, but we would still require the "displayVersion" in the "appsAndFeatures" key so the upgrade logic functions properly and will allow the publisher to determine what is displayed to the user.

In order not to have a broken experience when using the marketing version, all versions of manifests should have the correct "displayVersion".

[anaisbetts]

@denelon Sure, but again, please note #1187 (comment) - many many many people use older Squirrel.Windows versions

[denelon]

I completely understand. It's going to take years to clean up the experiences in cases where installers need to be fixed/modified/upgraded.

[denelon]

I'm not sure how we would be able to implement reliable behaviors customized to Squirrel without a reliable way to detect an installer was built with it. Even if we can specify in the manifest that an installer is Squirrel, we need to be able to verify that programmatically so we can safely change the behaviors. That would also likely depend on a new version of Squirrel.

[glen-84]

Apps will always "use old versions of Squirrel", it'll only get worse if this is not fixed soon. It displays the incorrect version number in "Installed apps" as well, it's not limited to WinGet.

[treysis]

Yes, please! 2024 is halfway through and there's no fix yet! It's not only affecting winget!

[treysis]

So I think it's better to pull all apps that use Squirrel.Windows from the winget repository until this issue is fixed and those apps move to a working version of Squirrel. This currently just messes up winget and is a nuisance to the winget userbase.

[anaisbetts]

I'm actually extremely Glad that WinGet cannot monitor Squirrel apps because this would at worst result in downgrades and corrupted user data. Consider the extremely common scenario:

1. User winget installs Discord (replace Discord with $YR_FAV_APP)
2. Squirrel auto-updates Discord to a version that WinGet doesn't manage, because WinGet will frequently be behind the official vendor's updates
3. winget upgrade compares installed version vs winget version and finds a newer version is installed than it knows about. What happens here? At best it does Nothing, at Worst, it decides to "upgrade" to the lower version.
4. Any data migration is now corrupted as we have paved over the migrated code with a possibly unmigrated one

What WinGet is effectively asking here is the ability to override the update intent of the app developer, a feature that has been frequently asked for by IT Admins but always WONTFIXed, because it is not Squirrel's job to dictate update policy, it gives app developers the tools to decide for themselves. If an app developer wants to add explicit WinGet support they are certainly free to do so, but we won't make that decision for them

[glen-84]

at Worst, it decides to "upgrade" to the lower version.

Huh? Why on earth would WinGet install a lower version?

Squirrel is broken, not WinGet.

[TemporaryAl]

I don't even get why there's still a discussion about this at all. The version number of the old app is being kept, the app is a new version number post autoupdate, this is a bug that needs fixing.

Winget is only really related to this because it happens to use this as a system to check for upgrades but the behaviour of Squirrel is wrong anyway

[anaisbetts]

Huh? Why on earth would WinGet install a lower version?

Read my reply, I described exactly how this could happen, but what it actually does I can't comment on, because I didn't write winget. I am describing a possible scenario that could happen should we "fix this bug".

this is a bug that needs fixing.

Thinking about what happens to existing users as an unintended consequence of a change, even if it wasn't "your fault", is a Very Important Thing To Do when writing installer software!

[BlockyTheDev]

3. at Worst, it decides to "upgrade" to the lower version

This can happen much more due to the current behaviour of Squirrel:

1. WinGet* compares the installed version with the package repository version and thinks an older app version is installed than actually installed.
2. The WinGet* Package Repository is behind the actually installed version of the app.
3. Now WinGet* is trying to "upgrade" to what it thinks is the latest version, which in reality is an older version as actually installed.
4. The result could be your described result: Corrupted data of the app.

*: WinGet used as a placeholder for many different patch management systems used by companies...

[anaisbetts]

@BlockyTheDev Hm, you're not wrong.

This probably requires a larger policy decision on WinGet's side, as to how it Generally Handles auto-updating apps. I would argue that apps that auto-update should probably be marked as such in the WinGet package manifest and just ignored, though I'm sure that this would not be Popular with the WinGet people!

(looking forward to all the 👎 emoji on that one 😂)

A PR that would imho be more reasonable for Squirrel to implement, is a way to conclusively detect whether an app is a Squirrel app (though I'd argue that we could more simply have a Discussion about what would be the best way to do that with existing code - i.e. something Squirrel promises Will Never Change that WinGet can rely on), which would at least give WinGet the ability to conclusively decide what to do

[BlockyTheDev]

This probably requires a larger policy decision on WinGet's side

But why should this be done on the WinGet/patch management systems side?

In my opinion WinGet/patch management systems works like they should in this case:

• Currently installed app version >= version from package repository -> No update available
• Currently installed app version < Version from package repository -> Update available -> In this case Squirrel can still update data without corruption, as the new installed version is always higher than the previous installed one.

I personally see no reason / use case where not updating the version is appropriate and does not cause more work for IT admins, users, app developers and others.

On the contrary, it would have another advantage:
The Windows settings would show the version that is actually currently installed and not the version of the initial installation. As a result, no users (including me) or the app support team, would be confused and think that the app (using Squirrel) is outdated.

[mdanish-kh]

Let's forget WinGet for a moment. I'd say majority of windows users go to Control Panel / Apps&Features when they want to uninstall an app or see more about it. Are we okay with the fact that the default experience of squirrel allows them to see an outdated version there?

[treysis]

Yeah, if WONTFIX is the ultimate answer, then instead of keeping the wrong version information in the registry (that is what Squirrel currently does!), don't write any version number at all to the registry to begin with. I think Squirrel.Cloud fixed this and does it correctly. There is no good reason to keep the wrong version information, regardless of winget.

[glen-84]

Read my reply, I described exactly how this could happen, but what it actually does I can't comment on, because I didn't write winget. I am describing a possible scenario that could happen should we "fix this bug".

I read your reply multiple times, and it doesn't explain why a package manager would ever install a lower version when an upgrade has been requested. That would be a serious bug.

You are quoting "fix this bug" as if to imply that this isn't a bug?

Thinking about what happens to existing users as an unintended consequence of a change, even if it wasn't "your fault", is a Very Important Thing To Do when writing installer software!

No, it is not the responsibility of installer developers to avoid fixing an obvious bug because an unrelated application might depend on the broken behaviour. You happen to be aware of WinGet, but what about all of the other software that may interact with software versions that you're not aware of?

What about simply reporting the correct version information to the operating system itself, and letting WinGet handle the package management?

This probably requires a larger policy decision on WinGet's side, as to how it Generally Handles auto-updating apps. I would argue that apps that auto-update should probably be marked as such in the WinGet package manifest and just ignored ...

They are already!

We just want the Squirrel installer to report the correct version information in the registry, as every other installer does on Windows.

something Squirrel promises Will Never Change that WinGet can rely on

You cannot expect WinGet (and other software) to special-case every installer in existence. If you write an installer for a specific operating system, you follow that operating system's conventions. In the case of Windows, it uses the registry.

Expecting software to search in directories, strip prefixes, sort by semantic version, etc., in order to simply read the currently-installed version, is madness.

[treysis]

Also, why was it working fine before (1.5.2) and what made you decide to change the original behavior (talking about breaking changes)?

[Anutrix]

First of all, thanks for maintaining this awesome project.
Except for this one issue, my experience with Squirrel.Windows has been better than other installation frameworks.

This probably requires a larger policy decision on WinGet's side, as to how it Generally Handles auto-updating apps. I would argue that apps that auto-update should probably be marked as such in the WinGet package manifest and just ignored, though I'm sure that this would not be Popular with the WinGet people!

(looking forward to all the 👎 emoji on that one 😂)

A PR that would imho be more reasonable for Squirrel to implement, is a way to conclusively detect whether an app is a Squirrel app (though I'd argue that we could more simply have a Discussion about what would be the best way to do that with existing code - i.e. something Squirrel promises Will Never Change that WinGet can rely on), which would at least give WinGet the ability to conclusively decide what to do

It's a Squirrel on Windows issue. It was never about WinGet. For example, I want it to show correct version in Control Panel.
Actual version:

What Squirrel.Windows tells application version is:

Hence, problem reproduced without winget.
Note another rare but significant problem during major Windows Upgrades because Windows itself needs to determine from registry and advise the user what apps will break going forward.

If at all Squirrel doesn't want to(or cannot) update version correctly/reliably on Windows, at least it's better to not set it in registry. Blank is better.

I haven't looked at Squirrel.Windows code before but once I get the time I will try to find the culprit logic and make a PR maybe. No promises though folks. Of course, I would be much happier if any contributor with Squirrel.Windows codebase experience can do it first.

The core logic for registry changes seems to be in https://github.com/Squirrel/Squirrel.Windows/blob/master/src/Squirrel/UpdateManager.InstallHelpers.cs .