[Package Issue]: Microsoft.PowerShell

[NJT145]

Please confirm these before moving forward

• I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
• I have not been informed if the issue is resolved in a preview version of the winget client.

Category of the issue

Installation issue.

Brief description of your issue

I tried to install it on machine scope, but it says that "The current system configuration does not support the installation of this package.". I used this code to install it: winget install --id=Microsoft.Powershell --source=winget --scope=machine.

Steps to reproduce

I used this code to install powershell core: winget install --id=Microsoft.Powershell --source=winget --scope=machine.

Actual behavior

Gives error: "The current system configuration does not support the installation of this package."

Expected behavior

Install the msi package (on machine scope).
(Note: I am using this workaround: winget install --id=Microsoft.Powershell --source=winget --scope=machine --version=6.0.0.0 and winget upgrade --id=Microsoft.Powershell --source=winget. However, this should not be necessary.)

Environment

[winget --info]
Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Screenshots and Logs

No response

[NJT145]

Update for my Note: I am using this workaround: winget install --id=Microsoft.Powershell --source=winget --version=6.0.0.0 and winget upgrade --id=Microsoft.Powershell --source=winget. However, this should not be necessary.

[Trenly]

Can you please provide your log files? I'm guessing that they will contain more detail, probably something along the lines of:

Device wide install for msix type is not supported in packaged context

Have you tried using it without --scope=machine ?

This may be related to microsoft/winget-cli#2855

Edit: @yao-msft - Verified this is the case using sandbox

[NJT145]

without --scope=machine, it works. But I want to install msi version, not the msstore version.
And it is a machine install at default. This code was working before but not working anymore.
I checked log and see that the install is only user scope and only with msstore version.
That should not be forced. I want to use msi version, not a restricted msstore app.

[NJT145]

winget install -e -i --id=Microsoft.PowerShell --source=winget --version=7.0.0.0 works, too. The problem is versions higher than that.

[NJT145]

I mean winget install -e -i --id=Microsoft.PowerShell --source=winget --scope=machine --version=7.0.0.0

[NJT145]

I found the problem. --scope=machine must be added to msi installation at lat version's manifest. It confuses when there are user scope installations and non-defined scope installations together. I will create a pull request for that.

[Trenly]

I found the problem. --scope=machine must be added to msi installation at lat version's manifest. It confuses when there are user scope installations and non-defined scope installations together. I will create a pull request for that.

I don't think that's accurate. MSI shouldn't need the scope set, since it can be installed in either. It seems the issue is that it is selecting the MSIX for you instead of the MSI. Even looking at version 7.0.0.0, there isn't a specified scope for the MSI installers.

[NJT145]

Okay I see that you are right. I continue to search.

[NJT145]

It happens after version 7.0.13.0 . Any ideas?

[NJT145]

I tried this: winget install -e -i --id=Microsoft.PowerShell --source=winget --scope=machine --version=7.0.2.0
my log file is this:

2023-01-28 05:21:31.133 [CORE] WinGet, version [1.4.10173], activity [{C37E21C4-960D-4CA2-A086-FCE61FE699AD}]
2023-01-28 05:21:31.134 [CORE] OS: Windows.Desktop v10.0.19045.2486
2023-01-28 05:21:31.134 [CORE] Command line Args: "C:\Users\nejat\AppData\Local\Microsoft\WindowsApps\winget.exe" install -e -i --id=Microsoft.PowerShell --source=winget --scope=machine --version=7.0.2.0
2023-01-28 05:21:31.134 [CORE] Package: Microsoft.DesktopAppInstaller v1.19.10173.0
2023-01-28 05:21:31.134 [CORE] IsCOMCall:0; Caller: winget-cli
2023-01-28 05:21:31.154 [CLI ] WinGet invoked with arguments: 'install' '-e' '-i' '--id=Microsoft.PowerShell' '--source=winget' '--scope=machine' '--version=7.0.2.0'
2023-01-28 05:21:31.154 [CLI ] Found subcommand: install
2023-01-28 05:21:31.154 [CLI ] Leaf command to execute: root:install
2023-01-28 05:21:31.158 [CLI ] Executing command: install
2023-01-28 05:21:31.160 [REPO] Named source requested, found: winget
2023-01-28 05:21:31.175 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2023-01-28 05:21:31.175 [CORE] Found matching extension.
2023-01-28 05:21:31.224 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.127.2100.984_neutral__8wekyb3d8bbwe\Public\index.db'
2023-01-28 05:21:31.224 [SQL ] Opening SQLite connection #1: 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2023.127.2100.984_neutral__8wekyb3d8bbwe\Public\index.db' [1, 40]
2023-01-28 05:21:31.225 [REPO] Opened SQLite Index with version [1.6], last write [2023-01-27 22:59:19.000]
2023-01-28 05:21:31.542 [REPO] Creating PredefinedInstalledSource with filter [None]
2023-01-28 05:21:31.542 [REPO] Creating new SQLite Index [4294967295.4294967295] at ':memory:'
2023-01-28 05:21:31.542 [SQL ] Opening SQLite connection #2: ':memory:' [6, 0]
2023-01-28 05:21:31.597 [REPO] Reading MSI UpgradeCodes
2023-01-28 05:21:31.635 [REPO] Examining ARP entries for Machine | X64
2023-01-28 05:21:31.801 [REPO] Examining ARP entries for Machine | X86
2023-01-28 05:21:31.913 [REPO] Reading MSI UpgradeCodes
2023-01-28 05:21:31.947 [REPO] Examining ARP entries for User | X64
2023-01-28 05:21:32.428 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\nejat\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2023-01-28 05:21:32.428 [SQL ] Opening SQLite connection #3: 'C:\Users\nejat\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db' [2, 0]
2023-01-28 05:21:32.429 [REPO] Opened SQLite Index with version [1.5], last write [2023-01-28 05:16:08.000]
2023-01-28 05:21:32.570 [CLI ] Found one app. App id: Microsoft.PowerShell App name: PowerShell
2023-01-28 05:21:32.572 [REPO] Downloading manifest
2023-01-28 05:21:32.572 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/manifests/m/Microsoft/PowerShell/7.0.2.0/0917-Microsoft.PowerShell.yaml
2023-01-28 05:21:33.506 [CORE] Download hash: b731d5f894d688a74b68afd901c327ebbab57542861aa1ac3d7975a3a642ede5
2023-01-28 05:21:33.506 [CORE] Download completed.
2023-01-28 05:21:33.507 [CLI ] Manifest fields: Name [PowerShell], Version [7.0.2.0]
2023-01-28 05:21:33.509 [CLI ] Starting installer selection.
2023-01-28 05:21:33.509 [CLI ] Installer [X64,msi,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2023-01-28 05:21:33.509 [CLI ] Installer [X86,msi,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2023-01-28 05:21:33.523 [CLI ] Terminating context: 0x8a150010 at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:a0

[Trenly]

my log file is this:

2023-01-28 05:16:44.458 [CLI ] Starting installer selection.
2023-01-28 05:16:44.459 [CLI ] Installer [X86,msix,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type msix
2023-01-28 05:16:44.459 [CLI ] Installer [X64,msix,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type msix
2023-01-28 05:16:44.459 [CLI ] Installer [Arm,msix,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type msix
2023-01-28 05:16:44.459 [CLI ] Installer [Arm,msix,User,en-US] not applicable: Machine is not compatible with Arm
2023-01-28 05:16:44.459 [CLI ] Installer [Arm64,msix,User,en-US] not applicable: Installed package type 'msi' is not compatible with installer type msix
2023-01-28 05:16:44.459 [CLI ] Installer [Arm64,msix,User,en-US] not applicable: Machine is not compatible with Arm64
2023-01-28 05:16:44.459 [CLI ] Completed installer selection.
2023-01-28 05:16:44.502 [CORE] DeliveryOptimization downloading from url: https://github.com/PowerShell/PowerShell/releases/download/v7.3.1/PowerShell-7.3.1-win-x64.msi

Interesting. I'm not sure what would be causing the discrepancy

[NJT145]

It is late at my location and I am sleepy, so I will take a look at that at tomorrow.
Anyone willing to test it, try to upgrade manifest schema version. I guess this can work...
You can try it from version 7.0.2.0 .

[NJT145]

And at version 7.3.1.0 there is a scope=user usage. watch out...

[denelon]

I had a quick chat with @SteveL-MSFT.

The Microsoft Store serves the MSIX package, and the community repository serves the MSI (except ARM64). This is intentional as a way to expose both installer types.

We still have work to do on the WinGet side to give the ability to specify the installer type. That would enable both to be in a manifest, and a user could select the one they prefer. We could also expose settings for the order of precedence for installer types.

• Specify InstallerType winget-cli#1166

It looks like there have been a few modifications of manifests by the community changing some of the "intended" behavior. We don't expect it was due to any ill will.

Mentioning @russellbanks for the most recent modification.

[russellbanks]

The Powershell MSIXBundle contains installers for x64, x86, arm, and arm64. My change added entries for all of those as before it meant that only arm and arm64 users were able to make use of the MSIX despite it working just fine on x64 and x86. I apologise if this caused issues though as it probably meant it defaulted to using MSIX over the MSI. It's been clarified in #93510 (comment) that winget will only use the MSI for Powershell so it should be fixed now.

[denelon]

@russellbanks, no worries. We're working on the "verified developer" feature to help prevent unintended changes in the future. We just didn't catch this one. I think this also calls out a need for a way to have some notes associated with packages to help clarify the "intended" behavior. This one was a bit tricky to reason about and wasn't obvious for an external party. You were just trying to be helpful. 😊

[NJT145]

now, it works for latest version. that's great. but for version 7.1.0.0 I got error for scope=machine. Not a problem while we only have msi installers. But still, some versions doesn't support scope parameter.

[denelon]

We found a couple of scope related bugs for MSIX and portable packages. They've been assigned to an engineer to fix:

• For msix installers, winget is not respecting scope=machine preference in settings.json. Only works correctly when "--scope machine" is explicitly passed in the command line. winget-cli#2876
• Installation of portable packages does not respect scope preference from settings.json winget-cli#2475

[NJT145]

For msi installers, I guess scope=machine can be a default, because all msi installers do a machine install. isn't that right?

[russellbanks]

For msi installers, I guess scope=machine can be a default, because all msi installers do a machine install. isn't that right?

MSI's can install in either user or machine. The MSI database specifies an ALLUSERS property, which can either be "1" (per-machine), "" (per-user), or "2" (the scope changes based on the user's privileges and the version of Windows).