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

Adds experiment to know if PATH is common issue. #1841

Merged
merged 4 commits into from
Jan 14, 2022

Conversation

Lewiscowles1986
Copy link
Contributor

@Lewiscowles1986 Lewiscowles1986 commented Jan 9, 2022

Was the solution to #1840. With thanks to @ItzLevvie


Apologies for my conduct on the ticket. It looks like I'd been working around this PATH entry missing with a few windows installer packages. No idea why it was not added.

Microsoft Reviewers: Open in CodeFlow

@Lewiscowles1986 Lewiscowles1986 requested a review from a team as a code owner January 9, 2022 18:25
@@ -95,7 +95,7 @@ These errors most commonly occur for one of following reasons. Please try out th
>`Get-AppxPackage microsoft.desktopappinstaller`

2. The App Execution Alias for the Windows Package Manager is disabled. You should enable the App Execution Alias for the Windows Package Manager. Go to `App execution aliases` option in `Apps & features Settings` to enable it.
3. The App Installer did not automatically add the PATH environment variable. You should add the path environment variable. The value to add is "%userprofile%\AppData\Local\Microsoft\WindowsApps".
3. The App Installer did not automatically add the PATH environment variable. You should add the path environment variable. The value to add is "%userprofile%\AppData\Local\Microsoft\WindowsApps". You can verify this by running `%LOCALAPPDATA%\Microsoft\WindowsApps\winget` from an administrator powershell. If the command runs then, but not before, then you very likely have a missing PATH environment component.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can verify this by running %LOCALAPPDATA%\Microsoft\WindowsApps\winget from an administrator powershell.

It should be For CMD , not powershell.
For Powershell ~\AppData\Local\Microsoft\WindowsApps\winget

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad. I copied from the wrong window. I've given two examples. One for powershell familiar, one for command-prompt, and labelled as such.

@ghost ghost added the Needs-Author-Feedback Issue needs attention from issue or PR author label Jan 9, 2022
@ghost ghost removed the Needs-Author-Feedback Issue needs attention from issue or PR author label Jan 10, 2022
@ghost
Copy link

ghost commented Jan 10, 2022

Another Note : Admin Shell is unnecessary and requiring such is problematic for MSIX packaged applications until it supports "Machine-wide install" and "Running as another users".

What happens when a Standard User opens an Admin Shell via UAC only to find that winget doesn't run ?! MSIX packaged applications to this date are registered Per-User Only and doesn't support Running as another user i.e requires User Interactive Login.

This is one of the major limitations of MSIX.
Winget is a MSIX packaged application. MSI or EXE packaged apps don't have these limitations.

So it's advised to remove Admin Shell requirement.

@denelon denelon merged commit 8ea9ef2 into microsoft:master Jan 14, 2022
@denelon
Copy link
Contributor

denelon commented Jan 14, 2022

Thanks for the PR! Documentation is often the unsung hero in software.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants