'Winget' command does not work

[djhalnon]

I've installed the App Installer package from the Microsoft Store, however, curiously, I can't run winget. When I do, I get: "'winget' is not recognized as an internal or external command, operable program or batch file."

Now, I've seen a lot of stuff about paths. Also curiously, though, "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps" is already in my PATH.

And also curiously, I've searched the entire drive for any file beginning with "winget", and came up with nothing whatsoever.

I have a feeling this thing never installed, even though it says it did and even though it shows in the Store app as "This product is installed."

Any solution? Or is this true "beta-ware" that really sometimes just doesn't work, and I should just forget about it?

[denelon]

@djhalnon If you are not on a Windows Insider build or part of the Windows Package Manager Insider group, it is likely you received the version of the App Installer that does not include the winget client.

https://github.com/microsoft/winget-cli#installing-the-client

You can download and double-click the installer from the https://github.com/microsoft/winget-cli/releases page.

Any newer version of the App Installer published to the store will automatically be updated on your system (assuming no Group Policy is blocking the store).

[arnitdo]

Facing a similar problem here. Installed it from the releases page. Searching the C:\ Drive for 'winget' returns no search results apart from Microsoft Store Search cache files. No application exists in WindowsApps\ as well.

Out of curiosity, what does the AppInstallerCLI.exe executable do? Is that supposed to be winget?

[mnpenner]

FWIW, I didn't get winget either when I went to the store page. Said I already had App Installer. But the "directly install" link from the blog post seemed to force an update, and now I have it.

[denelon]

Out of curiosity, what does the AppInstallerCLI.exe executable do? Is that supposed to be winget?

That is the name for the Windows Package Manager client .exe as compiled/built. We use and App Execution Alias to map winget.exe to AppInstallerCLI.exe.

[JoeLyga]

Facing the same issue. Running winget produces no output in powershell.

[denelon]

@JoeLyga are you a Windows Package Manager Insider or running a Windows Insider build?
How did you install the "App Installer"?

[billriess]

I'm also having the no output issue.

[impossiblynew]

This seems to be the same issue as #502 (I'm also having this issue)

[denelon]

The Windows Package Manager is distributed with the "App Installer". Make sure you have the correct version that includes the Windows Package Manager. In PowerShell:

PS C:\Users\denelon> Get-AppxPackage microsoft.DesktopAppInstaller


Name              : Microsoft.DesktopAppInstaller
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 1.11.11451.0
PackageFullName   : Microsoft.DesktopAppInstaller_1.11.11451.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.11.11451.0_x64__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.VCLibs.140.00.UWPDesktop_14.0.29231.0_x64__8wekyb3d8bbwe,
                    Microsoft.DesktopAppInstaller_1.11.11451.0_neutral_split.scale-100_8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Check to see that the version is greater than 1.11

If you do have the current version of the AppInstaller, the other areas to check are App Execution Alias settings as well as other troubleshooting steps in #502

[billriess]

I can confirm that the App Execution Alias is enabled and the Get-AppxPackage microsoft.DesktopAppInstaller gives the following results:

Name              : Microsoft.DesktopAppInstaller
Publisher         : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture      : X64
ResourceId        :
Version           : 1.11.11451.0
PackageFullName   : Microsoft.DesktopAppInstaller_1.11.11451.0_x64__8wekyb3d8bbwe
InstallLocation   : C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.11.11451.0_x64__8wekyb3d8bbwe
IsFramework       : False
PackageFamilyName : Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
PublisherId       : 8wekyb3d8bbwe
IsResourcePackage : False
IsBundle          : False
IsDevelopmentMode : False
NonRemovable      : False
Dependencies      : {Microsoft.VCLibs.140.00.UWPDesktop_14.0.29231.0_x64__8wekyb3d8bbwe,
                    Microsoft.DesktopAppInstaller_1.11.11451.0_neutral_split.scale-125_8wekyb3d8bbwe,
                    Microsoft.DesktopAppInstaller_1.11.11451.0_neutral_split.scale-100_8wekyb3d8bbwe,
                    Microsoft.DesktopAppInstaller_1.11.11451.0_neutral_split.scale-400_8wekyb3d8bbwe}
IsPartiallyStaged : False
SignatureKind     : Store
Status            : Ok

Running winget just gives no output. Curiously, the winget.exe is 0 bytes in the WindowsApps folder.

[billriess]

I noticed that running the winget command in a terminal immediately after logging in seems to work. There is likely some interference with another application causing no output. Windows Terminal is installed as is WSL2 with Debian.

[denelon]

The zero byte file is expected. The App Execution Alias maps winget.exe to the true executable. It acts similar to a symlink in *nix. I haven't seen other reports of interactions with WSL2 or any of the other specific distributions, but I'll keep that in mind as others report similar issues.

[impossiblynew]

I noticed that running the winget command in a terminal immediately after logging in seems to work. There is likely some interference with another application causing no output. Windows Terminal is installed as is WSL2 with Debian.

Just wanted to say that the same thing happened with me -- winget suddenly started working without me restarting or making any changes in the middle of a PowerShell session, and that I also have Windows Terminal and WSL2.

[A9G-Data-Droid]

I'm having this same issue. When I look at my App Execution Alias folder (\AppData\Local\Microsoft\WindowsApps) I see the alias pointing here:

la---           3/29/2021  8:23 AM              0 winget.exe -> C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.11.2521.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe

If I try to manually run the target of that alias I get:

The term 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.11.2521.0_x64__8wekyb3d8bbwe\AppInstallerCLI.exe' is not recognized as a name of a cmdlet, function, script file, or executable program.

If I try to manually browse to that location and try to run the exe I get an access denied error like this:

PS C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.11.11451.0_x64__8wekyb3d8bbwe> .\AppInstaller.exe
ResourceUnavailable: Program 'AppInstaller.exe' failed to run: Access is denied.At line:1 char:1
+ .\AppInstaller.exe
+ ~~~~~~~~~~~~~~~~~~.

This is odd because I am running an elevated Administrator PowerShell session when I get the access denied error. I think this might be the root cause for me.

[arnitdo]

Update : The winget command now works, and the executable is located in C:\Windows\System32. However, upon executing it, I get the following error

ResourceUnavailable: Program 'winget.exe' failed to run: The specified executable is not a valid application for this OS platform.At line:1 char:1
+ winget
+ ~~~~~~.

[A9G-Data-Droid]

You're stale @msftbot, we need developer action, not bot auto-closing. If a human wants to close the issue they will. Maybe you should be auto-closed.

[arnitdo]

I think this issue should be permanently kept open until a strong fix is found. It would be great if the bot could have this issue excluded

[aminya]

Please re-open this issue. It is not still fixed.

[denelon]

@aminya feel free to create a new issue with specifics for the specifics for your scenario. Let the community know what you've attempted so we can help troubleshoot. The original author for this Issue has closed it.

[heitoreleuterio]

I was with the same problem, winget wasn't working in PowerShell. Microsoft Store said that App Installer was already updated, but it wasn't.
Running the command Get-AppxPackage microsoft.DesktopAppInstaller I've the info that version on my system was actually 1.4, while the current version is 1.16.

The way I've found to solve this problem was install the current stable version on official Windows Package Manager repository:

https://github.com/microsoft/winget-cli/releases/tag/v1.1.12653

This is the last stable version in 01/12/2021. To install you just need scroll to the bottom of the page in Assets field, and install the Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle. This will force update.

[seanmcd27]

one problem here is that the windows update(or store update) version is out of sync and newer than the github release version. i currently (2022/03/02) have version 1.16.13405.0 of the desktopappinstaller package installed on my win 10 device. the currently latest released github version is 1.1.xxxx and the latest pre-release version is 1.3.xxxx. so, if the app installer store package was initially installed from a non-elevated user and then you try to use it from admin then the admin account's %localappdata% profile is completely missing the app execution alias .i.e c:\users<admin_account>\appdata\local\microsoft\windowsapps doesn't have an app execution alias reparse point for winget.exe . and, since the github version is older than the auto update version you can't force a re-install from an elevated command prompt because the installed version is newer. this seems broken. why are the versions out of sync in this fashion?

[denelon]

@seanmcd27 the App Installer version and the Windows Package Manager version only share the final part of the version:

PS C:\Users\denelon> winget --info
Windows Package Manager (Preview) v1.3.431-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22563.1
Package: Microsoft.DesktopAppInstaller v1.18.431.0

The App Installer version for the Windows Package Manager 1.1.z release is 1.16.z

[wangshanghai240]

我也有同样的问题，是最近才出现的，以前从未出现，我还安装了wsl2运行Ubuntu 22

[ubeydtalha]

go C:\Users"[YOUR_USERNAME]"\AppData\Local\Microsoft\WindowsApps

you will find winget there

[emoxam]

@JoeLyga are you a Windows Package Manager Insider or running a Windows Insider build? How did you install the "App Installer"?

I was at Windows Package Manager Insider, how can i check it ?
It stoped to work a few days ago. Why ?

[xodotLBO]

After latest app installer update I can't get winget to work
winget : The term 'winget' is not recognized as the name of a cmdlet, function, script file, or operable program. Check
the spelling of the name, or if a path was included, verify that the path is correct and try again.

I tried re-registering it, editing env. variables, updating everything.. nothing helps.
PS C:\WINDOWS\system32> Get-AppPackage -Name winget | Select Name, Version, Status

Name Version Status

---

Microsoft.Winget.Source 2023.622.905.772 Ok

[emoxam]

It seems for some reason we need to add this manually to PATH
%userprofile%\AppData\Local\Microsoft\WindowsApps\

[xodotLBO]

Already did, it didn't do anything.

[emoxam]

Already did, it didn't do anything.

It helped me.
I did this because of this

dir %userprofile%\AppData\Local\Microsoft\WindowsApps\ | findstr winget
16.08.2023 12:03 0 winget.exe

[xodotLBO]

Well i wish it helped me but doesn't seem to be working as it gives me same error that term winget is not recognized

[emoxam]

Well i wish it helped me but doesn't seem to be working as it gives me same error that term winget is not recognized

cd %userprofile%\AppData\Local\Microsoft\WindowsApps
winget

works ?

show me dir command output if it's not.

[xodotLBO]

It doesn't work, says the path doesn't exist.
Not sure why is it trying to path it thru c:windows
cd : Cannot find path 'C:\WINDOWS\system32%userprofile%\AppData\Local\Microsoft\WindowsApps' because it does not exist.

Edit: I fixed it by changing App execution aliases.. Can't believe that was the problem this entire time

[emoxam]

cd %userprofile%\AppData\Local\Microsoft\WindowsApps

It should not be powershell, it should be cmd console while you trying to cd.

What do you mean? What "App execution alias" ?

[xodotLBO]

cd %userprofile%\AppData\Local\Microsoft\WindowsApps

It should not be powershell, it should be cmd console while you trying to cd.

What do you mean? What "App execution alias" ?

Works fine in cmd.
App execution alias is exactly what it says, you can use search bar and see whats it like. I had winget com server, package manager and everything else disabled somehow even tho I didn't touch anything

[emoxam]

cd %userprofile%\AppData\Local\Microsoft\WindowsApps

It should not be powershell, it should be cmd console while you trying to cd.
What do you mean? What "App execution alias" ?

Works fine in cmd. App execution alias is exactly what it says, you can use search bar and see whats it like. I had winget com server, package manager and everything else disabled somehow even tho I didn't touch anything

So you just enabled all that is about winget ? And that was the fix ?

[xodotLBO]

Yea, I enabled everything related to it and now it works fine. I can post a picture if needed. But I never touched these settings, they disabled themselves after the update somehow

[emoxam]

Yea, I enabled everything related to it and now it works fine. I can post a picture if needed. But I never touched these settings, they disabled themselves after the update somehow

Can confirm it was disabled too at my colleague PC.

[ImAhmadAbdullah]

I did this to fix it: New-Alias -Name winget -Value "C:\Users\User\AppData\Local\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe"