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 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.

winget uses an "execution alias" to add itself to path. it should be in C:\Users%userprofile%\AppData\Local\Microsoft\WindowsApps
if it is enabled in windows settings->aplications->app execution alises

It did seem to activate it's alias correctly, but yet it still did not add to the PATH variable--however @aslze mentions he needed to log out and back in for it to work.

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.

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

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.

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?

My path is set correctly, but the alias didn't get setup.

Is there a way to manually add it? Or something else I can try?

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?

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 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'm having the same issue, and i used the same installation method. I couldn't notice any change in the Installation App.

BTW: I'm on v1803. (Need to get IT to upgrade me.)

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've the same issue the last four people above me have been facing.

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)

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.

@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.

After updating manually, Winget did not work. The solution that worked for me was to add an absolute address path to the enviromental variable of PATH C:\Users\%USERPROFILE%\AppData\Local\Microsoft\WindowsApps in addition to what was already there %USERPROFILE%\AppData\Local\Microsoft\WindowsApps , then log out and log back in to resolve issue.

Following the instructions from the automated email did not work, the manual install has a better success rate overall after installing on three machines.

@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?

@Pentao Try running the shell in administrative mode.

I ran into this today on a brand new machine and install. Rebooting (which logs me out, of course, like some folks have suggested above) made it work for me.

I don't think #235 is an exact duplicate. The focus of that issue is on the misleading and confusing message.

@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....

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?

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).

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

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

@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.

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 :)

@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.

@MisinformedDNA Oh dear. I've reopened this issue #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.

@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.

Run this to check version Add-AppxPackage -Path pathToAppXBundle if it's not right go click that appxbundle link

Wanted to chime in, I downloaded the latest appxbundle as of today from the releases section, installed it, and was not able to access "winget" from the command line or developer command prompt.

Reinstall did not help.

Once I added %userprofile%\AppData\Local\Microsoft\WindowsApps to my System's PATH variable, everything "just worked".

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.

Edit: Also, I suspect that adding it to the System's path (and not just the user's path) might be important here, (i.e. if you want to use it from an elevated command prompt.)

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.

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.

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";

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.

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

I don't think it is a different issue. -- Now that I think about it -- My command line sessions are run as an administrator -- so that would lead to all sorts of issues (including this one).

It could be a red herring but like... -- my understanding is that when you run things as administrator, it's a different user profile -- different %PATH% variables, etc. (machine path is still the same, but current user path is different).

At any rate, it should definitely not be installing it in the user's appdata - because that's not where software should ever be installed anyway. (It's for data, not software -- and maybe THAT is another bug -- but still, #wtf...)

Back on point though: if it's only updating the current user's path and not the machine's path, that would explain why running as an admin means the software doesn't work.

Also it would explain some of the discrepancies in this bug -- like someone said (paraphrased) "I had the same problem on my dev machine, but on a clean install everything just worked." -- because on a clean install they probably weren't running the command line as an admin (since that's not the default behavior, but it's a very common dev./power user thing to have setup).

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.

same here

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).

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.