Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The *.appxbundle installer does not automatically add the installation directory for winget.exe to the PATH environment variable in Windows 10 #210

Closed
jwheeler88 opened this issue May 19, 2020 · 48 comments
Labels
Area-External Issue-Bug It either shouldn't be doing this or needs an investigation.
Milestone

Comments

@jwheeler88
Copy link

jwheeler88 commented May 19, 2020

Brief description of your issue

When installing winget via the *.appxbundle installer, the installation directory for winget.exe is not automatically added by the installer to the PATH environment variable; this should have been added automatically so that the CLI commands can work out of the box.

Steps to reproduce

  1. Install winget from the v0.1.4331-preview release, using the *.appxbundle installer.
  2. View the systems PATH environment variable to confirm whether the installation folder for winget was added.

Expected behavior

The installation folder for winget is added to the system PATH environment variable.

Actual behavior

The installation folder for winget is not added to the system PATH environment variable.

Environment

[winget --info]
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.18362.778
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

Any other software?
@LuanVSO
Copy link

LuanVSO commented May 19, 2020

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
image

@aslze
Copy link

aslze commented May 19, 2020

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.

@jwheeler88
Copy link
Author

jwheeler88 commented May 19, 2020

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.

ApplicationFrameHost_7eBntTxvuM

@davefollett
Copy link

davefollett commented May 20, 2020

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

UPDATED: Added operating system Info

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

@denelon denelon pinned this issue May 20, 2020
@denelon denelon added the Issue-Bug It either shouldn't be doing this or needs an investigation. label May 20, 2020
@JHentges
Copy link

JHentges commented May 20, 2020

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.

@M2vH
Copy link

M2vH commented May 20, 2020

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?

@MisinformedDNA
Copy link

MisinformedDNA commented May 20, 2020

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?

@Acaico
Copy link

Acaico commented May 20, 2020

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?

@MisinformedDNA
Copy link

MisinformedDNA commented May 20, 2020

I joined the "Microsoft Package Manager Insiders Program", but it looks like I'm not getting the latest version:

image

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?

@Acaico
Copy link

Acaico commented May 20, 2020

I joined the "Microsoft Package Manager Insiders Program", but it looks like I'm not getting the latest version:

image

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.

@MisinformedDNA
Copy link

MisinformedDNA commented May 20, 2020

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

@Pentao
Copy link

Pentao commented May 21, 2020

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

winget

@nirinsanity
Copy link

nirinsanity commented May 21, 2020

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

@Amir-Abushanab
Copy link

Amir-Abushanab commented May 21, 2020

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)

@alexmacniven
Copy link

alexmacniven commented May 21, 2020

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

winget

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

@timmyb824
Copy link

timmyb824 commented May 21, 2020

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

@Chimera99
Copy link

Chimera99 commented May 21, 2020

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.

@Pentao
Copy link

Pentao commented May 21, 2020

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

2020-05-22_11-44-39

@MisinformedDNA
Copy link

MisinformedDNA commented May 22, 2020

@Pentao Try running the shell in administrative mode.

@denelon denelon added this to the Package Manager Backlog milestone May 23, 2020
@steveklabnik
Copy link

steveklabnik commented May 28, 2020

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.

@ermshiperete
Copy link

ermshiperete commented May 28, 2020

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

@kevsterd
Copy link

kevsterd commented May 29, 2020

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

@diablodale
Copy link

diablodale commented May 30, 2020

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?

@zooba
Copy link
Member

zooba commented Jun 2, 2020

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

@diablodale
Copy link

diablodale commented Jun 2, 2020

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

@SamHills
Copy link

SamHills commented Oct 20, 2020

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.

@quangkieu
Copy link

quangkieu commented Oct 20, 2020

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

@BrainSlugs83
Copy link

BrainSlugs83 commented Oct 22, 2020

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

@georg-eckert-zeiss
Copy link

georg-eckert-zeiss commented Dec 16, 2020

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.

image

same here

@zooba
Copy link
Member

zooba commented Jan 4, 2021

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

@Kein
Copy link

Kein commented Jan 7, 2021

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.

@denelon
Copy link
Contributor

denelon commented Apr 20, 2021

We are working on isolating this problem. It appears to be related to either Windows 10 and/or App Execution Aliases. I'm adding the area-external label to help remind us to follow up internally until we are able to find a resolution.

@denelon
Copy link
Contributor

denelon commented Sep 21, 2021

@jwheeler88 we've updated our troubleshooting guide. Let us know if this doesn't resolve the issue.

@denelon denelon closed this as completed Sep 21, 2021
@denelon denelon unpinned this issue Oct 1, 2021
@Sparx2
Copy link

Sparx2 commented Jan 18, 2022

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 image

Oh, my mind ! Its a my computer and profile and I can't login .I am a bit angry

@Sparx2

This comment was marked as off-topic.

@Masamune3210
Copy link

Masamune3210 commented Jan 18, 2022

I think you are confused, a execution alias is basically a shortcut to a program, a alias is another word for nickname or alternate name. They weren't referring to you by name

@argha2000
Copy link

argha2000 commented Apr 17, 2022

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.

I was facing the same issue for the last 1 month. Following these steps worked for me

@kaerez
Copy link

kaerez commented Jul 28, 2022

Issue still alive and well. How long does it take to fix the path? This is a store wide issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-External Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests