microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.36k stars 1.45k forks source link

Cannot install winget - An error occurred because a user was logged off. #3862

Open shalinikhare27 opened 1 year ago

shalinikhare27 commented 1 year ago

Brief description of your issue

I am not able to install the latest version of winget from Github using PowerShell Command on Windows 10.

Steps to reproduce

I am trying to install winget using the PowerShell command below on Windows 10:

powershell -command "Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle"

Expected behavior

Should install the latest version of winget

Actual behavior

I get the following error: `Error: Add-AppxPackage : Deployment failed with HRESULT: 0x80073D19, An error occurred because a user was logged off. Windows cannot install package Microsoft.DesktopAppInstaller_1.21.2771.0_x64__8wekyb3d8bbwe because this package depends on a framework that could not be found. Provide the framework "Microsoft.UI.Xaml.2.7" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 7.2109.13004.0, along with this package to install. The frameworks with name

"Microsoft.UI.Xaml.2.7" currently installed are: {} NOTE: For additional information, look for [ActivityId] 71e70201-feb0-0010-cd13-3a72b0fed901 in the Event Log or use the command line Get-AppPackageLog -ActivityID 71e70201-feb0-0010-cd13-3a72b0fed901 At line:1 char:1

Environment

Windows version:
Version    BuildNumber
-------    -----------
10.0.19043 19043      

The machine is logged in as a service account that has admin permissions.
stephengillie commented 1 year ago

Hi @shalinikhare27,

The user logoff error might be a "red herring" in that it might be a permissions error covering for a technical error. Omitting it leaves a much more actionable error:

Windows cannot install package Microsoft.DesktopAppInstaller_1.21.2771.0_x64__8wekyb3d8bbwe because this package depends on a framework that could not be found. Provide the framework "Microsoft.UI.Xaml.2.7" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 7.2109.13004.0, along with this package to install. The frameworks with name "Microsoft.UI.Xaml.2.7" currently installed are: {}

Basically it needs Microsoft.UI.Xaml.2.7 to be installed first. This can also be installed through an Add-AppxPackage command, though I don't have a good link to the installer itself.

mdanish-kh commented 1 year ago

@shalinikhare27 WinGet has a dependency on Microsoft.UI.Xaml.2.7 and Microsoft.VCLibs.14.Desktop. There is a sandbox script available over at Microsoft Learn to install WinGet with its dependencies. Can you try that script and see if it helps?

There is planned work to get these dependencies automatically with Repair-WingetPackage powershell cmdlet, but current workaround is to install these dependencies manually.

denelon commented 1 year ago

@shalinikhare27 did this resolve the issue for you?

shalinikhare27 commented 1 year ago

@denelon @mdanish-kh @stephengillie - Running sandbox script available over at Microsoft Learn to install WinGet with its dependencies did fix the issue around installing winget.

Questions:

  1. I tried running winget.exe install --id Microsoft.Git --disable-interactivity --accept-source-agreements --accept-package-agreements after installing winget to install Git and get the following error:
    Failed when searching source: winget An unexpected error occurred while executing the command: 0x8a15000f : Data required by the source is missing

No packages were found among the working sources.

  1. I was able to just run powershell -command Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle to install winget in my machine, without needing to install the dependencies. Is there a reason why it fails in machines that are running as a service account that has admin access where we need to run the sandbox script with more dependencies?

  2. Is the recommended way to install winget is running the sandbox script or just powershell -command Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle. I ask because we are automating winget installation in dev machines and then use winget to install and upgrade bunch of other tools. We want this to happen all non-interactively, completely automated.

denelon commented 1 year ago

Try running winget source reset --force in admin.

We're still working on code and documentation for guidance in unattended scenarios.

One of the areas we're exploring is to use "Repair-WinGetPackageManager" in the PowerShell module, but there are still some caveats between Windows PowerShell and PowerShell 7. There are also different behaviors related to provisioining MSIX packages in system context. There is a bit of a chicken and egg situation we're working through.

shalinikhare27 commented 1 year ago

@denelon - I ran winget source reset --force and get the following error still;.

██████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 1024 KB / 4.52 MB █████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.00 MB / 4.52 MB ███████████████████▒▒▒▒▒▒▒▒▒▒▒ 3.00 MB / 4.52 MB ██████████████████████████▒▒▒▒ 4.00 MB / 4.52 MB ██████████████████████████████ 4.52 MB / 4.52 MB

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0% ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0% ██████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 1024 KB / 4.52 MB █████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 2.00 MB / 4.52 MB ███████████████████▒▒▒▒▒▒▒▒▒▒▒ 3.00 MB / 4.52 MB ██████████████████████████▒▒▒▒ 4.00 MB / 4.52 MB ██████████████████████████████ 4.52 MB / 4.52 MB

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0% ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 0%

The msstore source requires that you view the following agreements before using. Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction The source requires the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

Failed when searching source: winget An unexpected error occurred while executing the command: 0x8a15000f : Data required by the source is missing

No packages were found among the working sources.

shalinikhare27 commented 1 year ago

This is what worked for me:

Problem 1

Error: Add-AppxPackage : Deployment failed with HRESULT: 0x80073D19, An error occurred because a user was logged off. Windows cannot install package Microsoft.DesktopAppInstaller_1.21.2771.0_x64__8wekyb3d8bbwe because this package depends on a framework that could not be found. Provide the framework "Microsoft.UI.Xaml.2.7" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 7.2109.13004.0, along with this package to install. The frameworks with name "Microsoft.UI.Xaml.2.7"

Solution for Problem 1

I ran the steps to install winget on sandbox with dependencies to install winget successfully.

Problem 2

Failed when searching source: winget An unexpected error occurred while executing the command: 0x8a15000f : Data required by the source is missing No packages were found among the working sources.

Solution for Problem 2

  1. winget source update
  2. powershell -command Invoke-WebRequest -Uri https://cdn.winget.microsoft.com/cache/source.msix -OutFile source.msix
  3. powershell -command Add-AppxPackage source.msix
  4. winget install --id Microsoft.Git --disable-interactivity --accept-source-agreements --accept-package-agreements
hfellner commented 1 month ago

Hi @shalinikhare27,

The user logoff error might be a "red herring" in that it might be a permissions error covering for a technical error. Omitting it leaves a much more actionable error:

Windows cannot install package Microsoft.DesktopAppInstaller_1.21.2771.0_x64__8wekyb3d8bbwe because this package depends on a framework that could not be found. Provide the framework "Microsoft.UI.Xaml.2.7" published by "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US", with neutral or x64 processor architecture and minimum version 7.2109.13004.0, along with this package to install. The frameworks with name "Microsoft.UI.Xaml.2.7" currently installed are: {}

Basically it needs Microsoft.UI.Xaml.2.7 to be installed first. This can also be installed through an Add-AppxPackage command, though I don't have a good link to the installer itself.

However, it seems like this is the actual issue. Neither Microsoft.UI.Xaml.2.7 nor Microsoft.VCLibs.14.Desktop can be installed using Add-AppXPackage in this situation because all of them fail with the same error. The script at Microsoft Learn mentioned earlier in this thread also fails with this error. The problem occurs only if the installation is run as a different user (e.g., Administrator) in the background. It works if run interactively by the logged on user. However, that is not an option when performing automated maintenance.

mdanish-kh commented 1 month ago

@hfellner Can you check if using the Repair-WinGetPackageManager PowerShell cmdlet works for you in provisioning WinGet on a clean environment? Try the following commands in Windows PowerShell / PowerShell

Install-PackageProvider -Name NuGet -Force
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery
Repair-WinGetPackageManager

After these commands finish, you can run winget -v to verify if WinGet is correctly installed

hfellner commented 1 month ago

@mdanish-kh To be clear, what I am trying to do is install Winget inside a VMware virtual machine, automated via the vmrun command, to execute commands inside the VM. This is comparable to running the commands in a scheduled task running as a different user. If I run the commands regularly inside a terminal window on the desktop everthing runs fine. This, however, is not an option in my case. So, that being said, I ran the commands you listed, and the result was the same:

Repair-WinGetPackageManager : Deployment failed with HRESULT: 0x80073D19, An error occurred because a user was logged 
off.