Portable app not executable in unelevated window

[Speed7811]

Brief description of your issue

I've a console app "pingt" and want that the user which installed it can use it in an elevated AND unelevated command line window. At the moment this doesn't work.

Steps to reproduce

Repro 1:

1. Open command line window (unelevated)
2. Enter "winget install -e pingt"
3. Open a new command line window (unelevated)
4. Type "pingt" -> Command not found!

This works:

3. Open a new command line window (elevated)
4. Type "pingt" -> Command found.

Repro 2:

1. Open command line window (elevated)
2. Enter "winget install -e pingt"
3. Open a new command line window (unelevated)
4. Type "pingt" -> Command not found!

This works:

3. Open a new command line window (elevated)
4. Type "pingt" -> Command found.

Expected behavior

Command should be found on an unelevated and elevated command line window

Actual behavior

Command was not found on an unelevated window

If I do this:

1. Open command line window (elevated)
2. Enter "winget install -e pingt --scope machine"

This works in elevated/unelevated window. But I don't want that any user needs to enter it. The package should be installed as simple as possible for the user.

Environment

Windows-Paket-Manager v1.6.2771
Windows: Windows.Desktop v10.0.19045.3448
Systemarchitektur: X64
Paket: Microsoft.DesktopAppInstaller v1.21.2771.0

[denelon]

The mechanism for handling a portable executables path depends on the scope a user installs it in as well as interaction with Developer Mode on Windows.

Developer Mode enabled - symbolic link created. Administrator installed - symbolic link created. User installed - path environment varible modified.

The terminal or CMD window most likely needs to be closed rather than just opening a new window to get the updated path.

[Trenly]

@denelon - I think this may actually be a bug in the way PATH is updated in Windows itself. I tested in Windows Sandbox.

1) Opened a non-elevated PowerShell session 2) winget install pingt -s winget 3) Closed PowerShell and re-open 4) Noted that pingt wasn't available in non-elevated powershell.exe or in elevated powershell.exe 5) Checked that symlink was created - it was 6) cd to application directory and tried running application directly - ran fine 7) Inspect system environment variables using the system settings dialogue - a) User PATH updated to include the Links directory - as expected - Used [x] to close b) Machine PATH not updated to include Links directory - as expected - Used [x] to close 8) Inspect PATH environment variable loaded in powershell.exe a) Non-elevated - Does not contain links directory b) Elevated - Does not contain links directory

However, manually triggering a re-save of the environment variables does the trick - 9) Close PowerShell 10) Open "Edit Environment Variables" dialogue - Open "Path" variable for machine scope - Click "Ok" to close 11) Open PowerShell 12) Inspect PATH environment variable loaded in powershell.exe - Links directory now present 13) Call pingt - Runs successfully

---

I don't know if there needs to be a flush of some form, or a double check that the changes were applied to the system, but it seems that in some cases, even though the variable appears to be updated and the new value shows in the system settings dialogue and the registry, that the PATH variable doesn't actually get updated.

I have a recording of this behavior if needed

[Speed7811]

@Trenly - I tried and check it like in your last comment (include the workaround) and I can reproduce it completly.

[Speed7811]

@Trenly - One question about "ElevationRequirement". I tried this settings in my manifest file but it seems to be ignored. That means if I set "ElevationRequirement" to "elevationRequired", open an unelevated window - I can install my app although it is not elevated. I tried it via winget install --manifest "PATH_TO_MY_MANIFEST" (Hint: Validation was successful). Is this behaviour correct?

[denelon]

@speed7811 that might be a bug. I'm chatting with the engineering team to discuss if we should either fix validation or determine the right way to support it via our implementation.

[Speed7811]

@denelon - Should I open a separate issue for the "ElevationRequirement"-Topic?

[denelon]

@Speed7811 yes, go ahead. We can at least discuss options or a decision on a separate issue.

[Speed7811]

@denelon - Done in #3756

[blaubaer]

Maybe we should adjust the way how we create the links in %USERPROFILE%\AppData\Local\Microsoft\WinGet\Links in general. Because as you need either elevated permissions or developer mode does it make behave strange, although it is easy to explain.

What if we create a wrapper executable instead a symlink? An very small executeable, which has the target location build-in and executes the target by handing over all provided arguments, environment variables, stdin, stdout, stderr, ...

Benefits:

1. These files can be created with any permission and also without developer mode.
2. There is software which is simply not compatible that it is symlinked and might fail.

I'm currently suffering with this behavior in winget-pkgs#123118 (by-side of the fact that .cmd and .bat are not supported in general for portable applications 😏).

[MichalStrehovsky]

I think the issue with PATH not getting refreshed from the registry was fixed in #3751.

[Speed7811]

Hey,

it looks like this is now fixed in #3751. In the current version 1.6.3133 I don't have any problems. Therefore I closed this issue now.