May I suggest 4. Repackage with a classic MSI/EXE instead of using “modern” packaging? It would also fix the Issue with non internet connected installations at the same time

You will be able understand once you start to see the world without your “Unix and Unix Clones” Glass.

see https://github.com/microsoft/winget-cli/discussions/1838#discussioncomment-1950473

mainly, it’s an issue because of the lack of interest of SSH/WinRM/Docker client programs.

Since other things lead me to come back to this issue, I will add that I have changed the name of the executable file in the package to be winget.exe (a while ago, so it should be in the latest public release) and thus potential option 1 for solving the issue. Yes, you would need to be remoted in on an account that has the package registered, but beyond that I think that directly running winget.exe from its location in the package should work. Unfortunately, that requires knowing the location of the package, but that is fairly easily solved:

PS> $wingetPath = Join-Path (Get-AppxPackage Microsoft.DesktopAppInstaller).InstallLocation "winget.exe"
PS> Invoke-Expression "& '$wingetPath'"
Windows Package Manager (Preview) v1.4.2161-preview
...

Not quite so clean as winget.exe or actual PowerShell, but you could wrap it in a function or script.

You will be able understand once you start to see the world without your “Unix and Unix Clones” Glass.

see #1838 (reply in thread)

mainly, it’s an issue because of the lack of interest of SSH/WinRM/Docker client programs.

what a ruse .
“unix of church glass”, everything is a untyped stream of text without any metadata. bacause parsing text is fun and we are in 1960…

That was about the lack of powershell support (waiting for it). I love powershell, I even install it on linux because I don’t like working with texts and “awk” and stupid unstructured data tools. In an ideal world, an application would be a group of classes that are grouped into either a graphical user interface or a command line-rich software like powershell, no one should deal with unstructured text.

I’m confused by this whole AEA problem when it seems like filesystem hardlinks would be the solution.

It would ideally be a symlink , hardlinks are hazardous. NTFS allow symlinks since Vista (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsymboliclinka) . I know that UWP seems to run on what’s basically a “chroot” (to use Unix terms, its a “silo”), so there must be a reason for AEA

What ended up happening is AEA is basically a “.lnk” file and those only work on “explorer.exe”. Who would have tough they would make the same mistake again… but here we are.

At least make the start shell API work on those then (I mean, this API https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw). Perhaps it does work and its my system that’s hosed, or perhaps I need to install the APPX on the system-wide account, who knows, all I know is that explorer is able to launch it, so I must also be able to launch it using the “ShellExecute”.

That elevation is connecting to powershell over OpenSSH.

I think the real problem is not only knowing the real directory by entering the reparse point, but also permissions.

Perhaps a simpler solution is to provide “shims” that do the proper calls to the proper RPC service. So shells don’t require any modification, just don’t use the WEA misfeature. https://www.tiraniddo.dev/2019/09/overview-of-windows-execution-aliases.html

Just throw them in some user’s public folder and ask the user to set its path to that. (incidentally “choco” seems to work)

@DylanWoodrow can confirm, happens to me even on my local machine, no ssh / remoting involved. When running as admin it fails, when running as currently logged in user, it works (but can’t make real use of winget as regular user - UAC on every updated package). Also doesn’t matter if I use powershell or cmd, same result (with different error message: The system cannot execute the specified program).

I am also still having this issue with build 1.17.3411.0 on 21H2. Notably when running Powershell as admin.

I am still seeing the issue, (Note: I am connecting to my VM using VSCode SSH feature)

ah, I see everyone is busy with App Execution Aliases , but that’s not the issue. the issue is MSIX packaged apps. MSIX packages can’t be run over SSH or WinRM , even worse one user can’t launch the app as another user. MSIX doesn’t support per machine class registration.

@dawin-knipp That’s one of the major limitations of the MSIX packaging format, has nothing to do with winget-itself. see https://github.com/microsoft/winget-cli/pull/1841#issuecomment-1009193824

Hmm, I tried this at computers with Windows 10 at work, and they have this same error message as in ranavale and ghost screenshots. EDIT. I tried few Windows 10 builds, and on everyone is this problem. On Windows 11 is not problem.

It fails with any ssh/remoting/docker exec session due to the issue that @JohnMcPMS described around AEAs not working. Extracting AppInstallerCLI.exe and the requisite dependencies (resources, dlls, etc) are the only way I’ve gotten it to work so far.

Can anyone else confirm? If this is fixed, I would like to close this issue.

@jedieaston, you are correct. During validation the script is run on the validation machine. It is not done via PowerShell remoting or SSH.

Agreed on 3, I think there is a case for it but if it is going to take tens of hours of work then there needs to be a justification that meets the bar. Need to ensure that it is actually the problem first, then we can put it on the backlog. But even if it was a go today, I don’t think we would see it released for at least a year and then it wouldn’t be serviced back to older Windows versions. We need the short term solution too.

By TBD I meant more “to be looked up because I remember seeing the PR but I have no idea when it was released, or if it even has been yet”. This was work specifically to enable creating the process directly on the package file in certain instances. Normally packaged processes need to be launched by special API to enable all of packagy goodness (don’t @ me), but this provided the ability to CreateProcess against the file and have it invoke the special API for you.

This is a similar issue to https://github.com/microsoft/winget-cli/issues/995.

If it helps the team narrow it down, it doesn’t just happen with winget.exe, but with any App Execution Alias (Windows Terminal registers wt.exe and it doesn’t work either). It happens over PowerShell Remoting and SSH (via the Windows built-in OpenSSH Server), and it happens even if winget works completely fine on the local system from a shell. It also happens if you are running Windows inside a docker container and attempting to execute winget via docker exec.

This is probably not a winget problem then, but @denelon can you ask whoever manages the App Execution Aliases stuff to look into it? It basically blocks using winget remotely unless you get creative.

Proofsies:

PS E:\> Enter-LabPSSession wingettest

[wingettest]: PS C:\Users\Administrator\Documents> whoami 
wingettest\administrator

[wingettest]: PS C:\Users\Administrator\Documents> winget --info
Program 'winget.exe' failed to run: The file cannot be accessed by the system.
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
 

[wingettest]: PS C:\Users\Administrator\Documents> python3
Program 'python3.exe' failed to run: The file cannot be accessed by the system.
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
 

[wingettest]: PS C:\Users\Administrator\Documents> python
Program 'python.exe' failed to run: The file cannot be accessed by the system.
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
 

[wingettest]: PS C:\Users\Administrator\Documents> wt 
Program 'wt.exe' failed to run: The file cannot be accessed by the system.
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
 

[wingettest]: PS C:\Users\Administrator\Documents> # Aw, beans!