@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

I seemingly had the same or similar PATH problem. I installed winget by joining the “Microsoft Package Manager Insiders Program” and installing through the Windows Store.

I installed winget.exe from the Windows Store as a standard user, Dave, and winget.exe was installed to: “C:\Users\Dave\AppData\Local\Microsoft\WindowsApps\winget.exe”.

When trying to run winget, I got an executable not found error. Looking at the PATH environment variable, I did have “C:\Users\Admin\AppData\Local\Microsoft\WindowsApp” set for the administrator account not for the Dave user or system wide. I also had the execution alias as mentioned above and logging out/in nor a reboot fixed things.

In order to make it work I had to add this to my system environment variable for PATH:

%userprofile%\AppData\Local\Microsoft\WindowsApps

As shown in this screenshot:

UPDATED: Added operating system Info

Windows 10 Pro (not insiders) Version: 1909 Build: 18363.836

Having the same issue here, I’m on version 1903. The app store confirms that the product is installed. I restarted the machine, but not App execution alias is added for winget.
Winget is not in my path: %userprofile%\AppData\Local\Microsoft\WindowsApps

Well, i do have the correct PATH setup for the Windows Apps folder. But inside of it there isn’t a Winget.exe file, so i get the same error with the winget command. I don’t have a Windows Insider Build, used the link to use the App Installer through the Windows Store. I reseted the App Installer app in the configurations, then tried to install it again. But there in’t any alias for Winget.exe nor an executable file. Any ideas?

winget uses an “execution alias” to add itself to path. it should be in C:\users\<username>\AppData\Local\Microsoft\WindowsApps
if it is enabled in windows settings->aplications->app execution alises

I’ve the same issue the last four people above me have been facing.

Having the same issue here, I’m on version 1903. The app store confirms that the product is installed. I restarted the machine, but not App execution alias is added for winget. Winget is not in my path: %userprofile%\AppData\Local\Microsoft\WindowsApps

I’m experiencing this too after signing up to the Windows Package Manager Insiders Program and attempted to download and install from the store.

Naturally, anything with write access (has nothing to do with an installer) to HKEY_CURRENT_USER\Environment key and value Path can change it from REG_EXPAND_SZ to REG_SZ.

I think it is reasonable for the infrastructure (Microsoft Store + Windows) to correctly check/set/install all needed dependencies when an app is installed via that store. Therefore…

1. Since app aliases are part of the app’s install
2. App alias functionality depends on PATH being correctly configured to %USERPROFILE%\AppData\Local\Microsoft\WindowsApps

That would require the dependency of app aliases to do at a minimum

1. make the alias in %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
2. ensure the PATH includes %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
3. ensure the PATH is REG_EXPAND_SZ. When it is only REG_SZ, then do the needed re/write of path back to REG_EXPAND_SZ

Seems to me the dependency handing of (Microsoft Store + Windows) is not doing steps 2 and 3. If the dependency handling is updated then it allows much…

1. Bugs due to the PATH reg key not being REG_EXPAND_SZ go away
2. When something else changes REG_EXPAND_SZ to REG_SZ at any time, then one or more aliases will fail. However, then the user can use the standard Windows App->Repair/Reset. Since the improved dependency handling will include steps 2 and 3 above…and therefore fix the registry key back to REG_EXPAND_SZ

windows terminal is experiencing the same problem. They identified it as the store/centennial/appx install process for appexecutionalias is not fully specifying the path to the aliases and instead using a path with embedded %USERPROFILE%. However that fails because the PATH environment variable in the registry is REG_SZ and not REG_EXPAND_SZ. Therefore that variable reference is not expanded.

Can someone at Microsoft escalate this shared issue to the Microsoft team(s) responsible for that area?

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

== Followed this steps, and it works. I tried winget install powertoys, it installs but, it is disappointing that I get a GUI prompt to continue, is there a way to escape this? Kinds of defeats the purpose of the tool, isn’t it?

Most of the reports in this thread seem to be people who are not getting the preview build of App Installer. Unfortunately, it’s not real obvious how to make sure you have the preview version here.

Yeah, that is the issue I am facing too. I applied for the preview program, got an email asking to install the Preview version on App Installer. But I don’t see any updates that are available in the store.

Running Get-AppxPackage Microsoft.DesktopAppInstaller in PowerShell will show the current package version though (I don’t know the right one myself, but a few contributions should show a pattern fairly quick).

My version is 1.0.32912.0

Windows adds the PATH entry itself - it’s part of your default user profile, and nothing to do with any particular APPX installer or even the Store. Changing from REG_EXPAND_SZ back to REG_SZ will be due to a third-party installer. I’ve been tracking issues like this for a while, as they affect the Centennial package of Python.

We’ve already fixed a few issues relating to apps disabling or resetting their aliases on package update, and also fixed a regression in a security patch late last year. The first couple of issues could have been either of those (though if you’ve got WinGet you should be on an insider build with fixes for those… so I’m still leaning towards third-party installer).

Most of the reports in this thread seem to be people who are not getting the preview build of App Installer. Unfortunately, it’s not real obvious how to make sure you have the preview version here. Running Get-AppxPackage Microsoft.DesktopAppInstaller in PowerShell will show the current package version though (I don’t know the right one myself, but a few contributions should show a pattern fairly quick).

This MUST be part of your $PATH variable:

%userprofile%\AppData\Local\Microsoft\WindowsApps

without the above in $PATH NONE of the Apps installed in WindowsApps can be executed from shell.

Don’t know, if the above directory is part of $PATH by default?

I just installed the appxbundle and I could not immediately run winget even spawning a new console. I thought it was not added to the PATH. I had to log out and log in for it to work.

Why is the installer putting Winget in the current user’s localAppData directory? That makes it usable only by the current user. It should install to either %ProgramFiles%, %ProgramFiles(x86)% or %windir%\System32 so it will be accessible to all users. This is a serious problem because I have a script that I run in Audit mode to install all my standard apps before running SysPrep, so WinGet gets installed to Administrator’s localappdata. The Administrator account does not survive Sysprep, so WinGet disappears and Cmd throws an error when I try to run Winget after SysPrep finishes.

@Caltor I’ve been waiting for 25 days and it still doesn’t work.

Get-AppxPackage Microsoft.DesktopAppInstaller still returns Version: 1.0.32912.0.

Does anyone know how to add alias manually into %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\ ? It does look like your basic soft symlink but it isnt, it some kind of hybrid between shortcut and symlink because it respects the startup path so naturally, creating just symlink for AppInstallerCLI.exe does nothing and creating basic windows shortcut/LNK also wont work, obviously.

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

For anybody else following this, to install the appxbundle you can open PowerShell (no need for admin as it installs in user account) and enter the following command replacing pathToAppXBundle with the downloaded AppxBundle file.

Add-AppxPackage -Path pathToAppXBundle

It’s a shame this isn’t working for lots of us though and we are having to install manually as this makes it difficult to get traction on this solution and we lose the benefit of automatic upgrades via the Store. I had the same issue as several people here that the App Installer is already showing as Installed before I signed up for the App Installer Insider program and there doesn’t seem to be any way to coax it into reinstalling. I think I might open a new issue for this but I expect it is a limitation of the Microsoft Store rather than something that can be fixed by a PR on this project.

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

Had the same on W10 2004 Build.19401 today. As above, installed the App Installer package from store then pulled latest version from GH…

@Pentao Try running the shell in administrative mode.

Same as the above, I installed through the App Store and restarted my machine (build 19041), and confirmed that %USERPROFILE%\AppData\Local\Microsoft\WindowsApps is in my PATH too.

However, winget is not recognized as a command (running from PS 7 if that makes any difference)

I joined the “Microsoft Package Manager Insiders Program”, but it looks like I’m not getting the latest version:

Hmmm… I just noticed something. The project readme file says “Windows 10 1709 (build 16299) or later” and the email says “Windows 10, version 1809 (or later)”. Which one is it?

I installed via the via the *.appxbundle installer a few minutes ago and was able to open a CMD and “winget show firefox” immediately: no problem found. I am logged into Windows as an administrator, in case that’s pertinent.

The Python redirector is in the AppInstaller package along with winget because it was a sensible place to put it, that’s all. It’s unrelated to (and predates) Winget.

As for the install location, all the application files go into ProgramFiles, but there’s still a bit of per-user registration that makes it look like a per-user install. That gives each user their own “view” of it, even though the entire install is shared (and secured).

This particular package should be automatically installed for all users though, so you ought to have Winget as admin. However, I’m guessing the global alias is not being created for users who are not logged in (I’m not 100% sure how that bit gets handled, but some of the Winget team are close enough to the right people to find out).

@SamHills I think your problem is different issue. You should open it in new issue

I’ve noticed the problem with the app aliases not being available - it appears as though the problem is that the alias directory itself is not on the path (and periodically disappears when you manually add it).

Insert this into your Powershell profile to manually add it to your path for each session.

$env:Path += ";$env:LocalAppData\Microsoft\WindowsApps";

I’ve been having a similar issue. It looks like the appxpackage installer installs a link to the python page on windows store, instead of an app that actually does anything. I thought maybe it was a dependency or prerequisite issue so I tried installing the Python from the Windows Store, but it didn’t solve anything.

If it works for you without adding it, then you must already have that as part of your PATH – maybe some other dev tool you have installed added it for you – but it’s clearly not the default, so please add this to your installer.

I also had this issue on one of my devices, but this week I installed it from the appxbundle on a Windows 2004 clean install and it worked right away without anything, so I guess it depends on some other factors.

@MisinformedDNA Oh dear. I’ve reopened this issue https://github.com/microsoft/winget-cli/issues/391 for you. Might be best to post your comments there or open your own new issue, as this issue is for the problem with the PATH.

I had the same issue as several people here that the App Installer is already showing as Installed before I signed up for the App Installer Insider program and there doesn’t seem to be any way to coax it into reinstalling.

As per Sayak’s comment this should resolve itself given time. Lots of time! Like go to bed and wait until tomorrow sort of time 😃