Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support special behavior for upgrading Squirrel applications #1748

Open
jedieaston opened this issue Nov 28, 2021 · 5 comments
Open

Support special behavior for upgrading Squirrel applications #1748

jedieaston opened this issue Nov 28, 2021 · 5 comments
Labels
Issue-Feature This is a feature request for the Windows Package Manager client.

Comments

@jedieaston
Copy link
Contributor

jedieaston commented Nov 28, 2021

Description of the new feature / enhancement

While investigating #1747 I found out that the Squirrel installer has a special way to do upgrades. Namely, it uses a Update.exe file inside the application's install directory (usually User\AppData\Local\$AppName) with some different arguments to execute it (silent upgrade appears to be supported). WinGet should support running this executable with the correct options to upgrade in lieu of running the installer over again, which can in certain cases (again, #1747) cause unexpected behavior.

It's worth noting that Teams is one of the applications that uses the Squirrel installer1, so this may be part of the answer to that problem.

Proposed technical implementation details

A new InstallerType (squirrel) that has defaults for silent install arguments (/s) and for upgrading using the Update.exe file instead of the installer. (This will require winget having some way of figuring out the install directory for the app. Squirrel applications seem to be good about setting the InstallLocation key in the ARP Table, and the Update.exe file is in that directory).

Footnotes

  1. If you want to know where the madness with the machine wide installer came from, check it out here

@jedieaston jedieaston added the Issue-Feature This is a feature request for the Windows Package Manager client. label Nov 28, 2021
@ghost ghost added the Needs-Triage Issue need to be triaged label Nov 28, 2021
@denelon denelon removed the Needs-Triage Issue need to be triaged label Nov 29, 2021
@denelon
Copy link
Contributor

denelon commented Nov 29, 2021

Related to:

@xarthurx
Copy link

As of today, the issue for the Fork software is still unresolved.
Every time I got an update, the info is lost.

@xarthurx
Copy link

Another half year, and as of today, the issue for the Fork software is still unresolved.
Every time I got an update, the info is lost.

@xarthurx
Copy link

@denelon Is there anyone working on this issue?

@denelon
Copy link
Contributor

denelon commented Aug 28, 2022

@xarthurx no, this is a fairly large feature. We have to fundamentally change the way we're calling installers to watch an entire process tree.

Related to:

@denelon denelon modified the milestones: Backlog-Client, v.Next-Client Aug 28, 2022
@denelon denelon removed this from the v.Next-Client milestone Nov 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Feature This is a feature request for the Windows Package Manager client.
Projects
None yet
Development

No branches or pull requests

3 participants