winget install --scope machine stopped working

[intelliIT]

Brief description of your issue

when executing with the flag --scope winget is resulting in errors. i recognized as i did some machine installs with the --scope machine before, which now dont work anymore.

winget install WireGuard.WireGuard -h --scope machine
winget install AnyDeskSoftwareGmbH.AnyDesk -h --scope machine
winget install SlackTechnologies.Slack -h --scope machine
winget install Google.Chrome.EXE -h --scope machine
winget install Adobe.Acrobat.Reader.64-bit -h --scope machine
winget install Microsoft.VisualStudioCode -h --scope machine
winget install LocalSend.LocalSend -h --scope machine

Steps to reproduce

run winget install <package> --scope user|machine

Expected behavior

run the installer as expected, resulting in either machine- or user-wide available applications.

Actual behavior

errors depending on the scope.

Environment

Windows Package Manager v1.8.1911
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.3880
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1911.0

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• Winget --scope machine not working for appx applications (#3553), similarity score: 0.83
• winget list --scope machine fails with an error (#3898), similarity score: 0.82
• Access denied error when using --scope machine on standard user (#4410), similarity score: 0.79
• unable to install Ms Store package using --scope command (#2151), similarity score: 0.78

Closed similar issues:

• Windows Terminal can only be installed in user scope (#1979), similarity score: 0.77

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[denelon]

WireGuard only has "machine" scope defined in the manifest so there is no "user" install supported: WireGuard.WireGuard 0.5.3

AnyDesk 8.0.11 is the same.

Not all packages support both scopes. The manifest will have metadata regarding any defined/supported scopes as long as the manifest author has included them.

The error in the screenshot related to the predefined source, is what I see as the problem in the flow. Given the subsequent install command worked without passing in scope, I believe it to have been a transient error unless passing the machine scope causes the same failure again. Note, since WireGuard only has "machine" scope defined, that install would have been a machine wide install.

If you see any failures, you can always run the command again with "--verbose-logs --logs" to run with extra logging and open the directory to the logs for troubleshooting. There you would see the logic WinGet is using for installer selection, and any problems related to scope show up there.

[MarcoBuess]

@denelon I wanted to report a similar issue, where there are inconsistencies with the --scope parameter IMO. I had an encounter with Microsoft.DotNet.DesktopRuntime.6 where both --scope machine as well as --scope user yield No applicable installer found; see logs for more details.. Package installation works if you omit the --scope parameter, but its unclear to me which scope it is using in that case. Is there any documentation you can point me to?

EDIT: CLI version is v1.8.1911

[denelon]

No scopes are specified in the latest version of the manifest. I'm not sure what the default scope is.

@mthalman can you shed any light here?

[mthalman]

The default scope for .NET installers is machine.

[MarcoBuess]

Is it a general thing that machine scope is preferred now if --scope is omitted, or is this specific to .NET or the distinct manifest of a specific app? winget show doesn't hint any information on which scope is used in the case of .NET.

[denelon]

Since there is no scope listed in the manifest today, WinGet doesn't know "ahead of time" what's going to happen. I'll work with the team to get the scope added so WinGet can be a bit more informative for this package.

[MarcoBuess]

@denelon Just for my understanding, do you mean added in general to manifest files so one has to specify it, or to the manifest of .NET specifically?

[denelon]

In this case, the manifest of .NET specifically. WinGet supports a very large swath of functionality via manifests with optional fields. It's more a matter of the domain experts for the package understanding the nuances of building the "best" manifest possible to help customers "fall into the pit of success".

[intelliIT]

@denelon thanks for the clarification and sorry for the late response. that makes totally sense, weird thing, it was working with the "--scope" parameter on some machines before i had the issues. would it also be possible to default to the "working" scope with some kind of warning message or prompt, when the requested scope isnt available?

[denelon]

The "default" behavior with a command-line argument is to treat it as a "requirement". If it can't be honored, the CLI will fail.

The settings have a notion of a "preference" or a "requirement". If it's a preference and it can be honored it will, but alternates are allowed. Any "requirement" in settings behaves as an argument in the CLI.