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

oh-my-posh installed another copy in Program Files (x86) when updating it via winget with admin privilege #5988

Closed
1 task done
Dilant opened this issue Dec 9, 2024 · 17 comments
Assignees
Labels
🐛 bug Something isn't working

Comments

@Dilant
Copy link

Dilant commented Dec 9, 2024

Code of Conduct

  • I agree to follow this project's Code of Conduct

What happened?

I have an existing installation in ~\AppData\Local\Programs\oh-my-posh\bin\oh-my-posh.exe.

Now I'm launching a pwsh shell with admin privilege. When I use either winget update JanDeDobbeleer.OhMyPosh or winget update -i JanDeDobbeleer.OhMyPosh, the installer instantly installs another copy as C:\Program Files (x86)\oh-my-posh\bin\oh-my-posh.exe, without any option to let me choose another installation directory. And after this, the older installation is untouched, I can see two Oh My Posh items in the control panel, and I can find the files of the older installation on my disk.

When I use winget download JanDeDobbeleer.OhMyPosh and double-click to install, it can correctly update my existing installation and not create a new one. (And it doesn't trigger an elevation prompt)

I haven't tried to update in a shell without admin privilege, but I do remember in former versions the installer can still correctly update the existing installation even if updated via a privileged winget.

Theme

a slightly modded version of ys.omp.json

What OS are you seeing the problem on?

Windows

Which shell are you using?

powershell

Log output

<not relevant>
@Dilant Dilant added the 🐛 bug Something isn't working label Dec 9, 2024
@JanDeDobbeleer
Copy link
Owner

@Dilant what's the previous version's number? We switched installer technology and that could be the root cause here. If so, there's nothing we can do other than you uninstalling that one using the add/remove programs functionality in Windows settings (that one will also show the version).

@Dilant
Copy link
Author

Dilant commented Dec 9, 2024

@JanDeDobbeleer the previous version is v24.11.4, and I'm going to update it to v24.12.0

@Dilant
Copy link
Author

Dilant commented Dec 9, 2024

I just tried again, and I can reproduce it.

  1. Download https://github.com/JanDeDobbeleer/oh-my-posh/releases/download/v24.11.4/install-x64.msi, and double click it to install v24.11.4. It is located at ~\AppData\Local\Programs\oh-my-posh\bin\oh-my-posh.exe
  2. Launch Windows Terminal with admin privilege, and it starts PowerShell 7.4.6.
  3. winget update JanDeDobbeleer.OhMyPosh (output below)
$ winget update JanDeDobbeleer.OhMyPosh
已找到 Oh My Posh [JanDeDobbeleer.OhMyPosh] 版本 24.12.0
此应用程序由其所有者授权给你。
Microsoft 对第三方程序包概不负责,也不向第三方程序包授予任何许可证。
正在下载 https://github.com/JanDeDobbeleer/oh-my-posh/releases/download/v24.12.0/install-x64.msi
  ██████████████████████████████  5.65 MB / 5.65 MB
已成功验证安装程序哈希
正在启动程序包安装...
已成功安装
  1. Now I have two Oh My Posh entries in control panel and two oh-my-posh.exe on my disk.

image

@JanDeDobbeleer
Copy link
Owner

This could be an MSI restriction, as I know it uninstalls when you upgrade as the same user (admin or regular), I validated that use-case.

@JanDeDobbeleer
Copy link
Owner

JanDeDobbeleer commented Dec 9, 2024

@Dilant I can't reproduce this when installing using the installer itself, that one always overrides the previous installation as of v24.11.3

EDIT: this installs as a local package as well this way, not with ALLUSERS=1.
EDIT2: this can indeed be an MSI restriction as: Once Windows Installer 5.0 installs an application, it uses the same installation context for all subsequent updates, repairs, or removal of the application. source.
EDIT3: I will probably use the UpgradeBehavior property with uninstallPrevious to work around this, but this is not supported from an MSI POV.

@Dilant
Copy link
Author

Dilant commented Dec 9, 2024

I just tried to use winget without admin priviledge, but this time, it shows an elevation prompt forcing me to install it as admin.

I've captured the command line of the installation process:

"C:\WINDOWS\System32\msiexec.exe" /i "C:\Users\Dilant\AppData\Local\Temp\WinGet\JanDeDobbeleer.OhMyPosh.24.12.0\install-x64.msi" /passive /norestart /log "C:\Users\Dilant\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-JanDeDobbeleer.OhMyPosh.24.12.0-2024-12-09-16-43-55.487.log" INSTALLER=winget ALLUSERS=1

I see ALLUSERS=1 here, I think either winget or the package is doing something weird here. (sorry I'm not familiar with winget)

And output of winget: (I cancelled the installation process)

$ winget update JanDeDobbeleer.OhMyPosh
已找到 Oh My Posh [JanDeDobbeleer.OhMyPosh] 版本 24.12.0
此应用程序由其所有者授权给你。
Microsoft 对第三方程序包概不负责,也不向第三方程序包授予任何许可证。
正在下载 https://github.com/JanDeDobbeleer/oh-my-posh/releases/download/v24.12.0/install-x64.msi
  ██████████████████████████████  5.65 MB / 5.65 MB
已成功验证安装程序哈希
正在启动程序包安装...
// Elevation prompt showed here and I cancelled it
你已取消安装。
安装程序失败,退出代码为: 1602
安装程序日志在以下位置可用: C:\Users\Dilant\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-JanDeDobbeleer.OhMyPosh.24.12.0-2024-12-09-16-37-06.162.log

The aformentioned log file (Winget-xxxxx.log) didn't provide any useful infomation.

MSI (s) (8C:C0) [16:37:20:604]: Product: Oh My Posh -- Installation failed.

MSI (s) (8C:C0) [16:37:20:604]: Windows Installer 已安装产品。产品名称: Oh My Posh。产品版本: 24.12.0。产品语言: 1033。制造商: Jan De Dobbeleer。安装成功或错误状态: 1602。

用户取消了安装。
C:\Users\Dilant\AppData\Local\Temp\WinGet\JanDeDobbeleer.OhMyPosh.24.12.0\install-x64.msi

@Dilant
Copy link
Author

Dilant commented Dec 9, 2024

I can't reproduce this when installing using the installer itself

@JanDeDobbeleer Yeah, I can't reproduce this when directly using the installer file, either double-clicking it or launch it from command line .\install-x64.msi, either giving it admin privilege or not.

Seems that the problem only happens when using winget. (winget or something related to it automatically appends ALLUSERS=1 to the installation process?)

@JanDeDobbeleer
Copy link
Owner

@Dilant ALLUSERS=1 is correct from winget though. They add it when you're administrator, otherwise it will still be a local install. It makes sense in a way, the local installer doesn't do that on its own.

This is all normal behavior though. The MSI is always going to respect its previous installation method, so switching between user and machine isn't supported unless you uninstall first. I can add that to winget, but not to the standalone installer.

@Dilant
Copy link
Author

Dilant commented Dec 10, 2024

ALLUSERS=1 is correct from winget though. They add it when you're administrator, otherwise it will still be a local install.

Does "when I'm admin" mean my account type is admin (whether elevated or not), or now I have admin rights (elevated)? If that's the former case, it all makes sense. (See the repro above, it asked me to elevate when I hadn't)

switching between user and machine isn't supported unless you uninstall first

I don't want to switch between user and machine installation, I just want to keep my current config. Now winget doesn't try to keep my config, it always tries to do (another) machine installation.

@JanDeDobbeleer
Copy link
Owner

@Dilant when you're in an elevated prompt, it seems winget itself adds the ALLUSERS property. This is probably by design, and the MSI will always respect the way it's installed. To only have a user installation, uninstall oh-my-posh, then install from a non elevated prompt, or specify the --scope user parameter.

@Dilant
Copy link
Author

Dilant commented Dec 10, 2024

then install from a non elevated prompt, or specify the --scope user parameter

No, either of them doesn't work.

  • Install from a non-elevated prompt: it forces me to elevate, or the installation is cancelled. See this.
  • Specify the --scope user parameter: now winget says "no package found matching input criteria", and I still cannot update it. Tried in both elevated and non-elevated shell.

EDIT: winget install JanDeDobbeleer.OhMyPosh --scope user seems working, and it did a successful user-scope update instead. I'll track its status on the next update.

@13xforever
Copy link

It's still installing to user profile without elevation by default, but forces elevation on upgrade with the latest v24.12.0

@vinothvkr
Copy link

It's still installing to user profile without elevation by default, but forces elevation on upgrade with the latest v24.12.0

Yes it opens UAC prompt, when doing winget upgrade JanDeDobbeleer.OhMyPosh. I currently have user scope installation with version 24.11.4 trying to upgrade to v24.12.0.

@Dilant
Copy link
Author

Dilant commented Dec 19, 2024

TL;DR workaround: use winget install JanDeDobbeleer.OhMyPosh --scope user to update your user scope installation (either elevated or non-elevated shell is okay)


I'm updating from v24.12.0 to v24.15.1, everything behaves the same as before:

  • winget install JanDeDobbeleer.OhMyPosh --scope user succeeds to do a user scope installation, from either elevated or non-elevated shell.
  • winget update JanDeDobbeleer.OhMyPosh --scope user always fails, saying "no package found matching input criteria", from either elevated or non-elevated shell.
  • winget update JanDeDobbeleer.OhMyPosh always do a machine scope installation, which will co-exist with a user scope installation (if you have one one). It fails to respect the way the package was installed before, and forces to elevate in a non-elevated shell.

@13xforever @vinothvkr Just to inform that here's a workaround.


I did my own investigation on the installation recipes, and I think it's sane.

@JanDeDobbeleer Can you try to reproduce what I said above, and see if there is anything which can be improved?

e.g.

  • Is winget failing to choose a user scope recipe? Maybe try to place user-scope recipes before machine-scope recipes.
  • Is winget failing to detect that the former installation is a user scope one? Maybe check if there's any extra flag which should be written to registry by the installer, so that winget can correctly detect it.

If there's anything wrong with winget, we should forward this issue to the winget team. I really want to figure out what's happening here, everything is contradicting with common sense and Microsoft's statement of keeping context on upgrade.

@JanDeDobbeleer
Copy link
Owner

@Dilant I just did an installation on a new machine, it does not pop up UAC when using winget install JanDeDobbeleer.OhMyPosh, it just installs for the current user. The ONLY way this can happen is when you previously installed as admin (or elevated) as the MSI will always respect that. It's one or the other, you can't switch that without uninstalling first.

@Dilant
Copy link
Author

Dilant commented Dec 25, 2024

Seems weird, let me try some different system setups later (including those which never installed OMP before).

My current system is Windows 11 Pro 27764 (Insider Preview - Canary), with Dilant as the only user, running winget v1.9.25200, if you need these info.

@JanDeDobbeleer
Copy link
Owner

Related to microsoft/winget-cli#5099

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants