-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
How-to guide for installing Microsoft.DesktopAppInstaller non-interactively #2434
Comments
#2436 helps. |
I think this may also be related to #401 |
@cdhunt there is also an "--accept-package-agreements" argument to handle those. |
I added both and it still prompts on the first install unless you visit the MS Store interactively first. |
Can you share a screen recording or something to help reproduce that? You should be able to:
without having to interactively accept an agreement prompt. The agreements still get displayed, but you shouldn't have to interact with them.
Note: This assumes you are running at least the stable version of 1.3 or newer. The bug requiring MSA authentication to the Windows Store was fixed in a 1.3 preview build. |
I will re-test. When I encountered this it was 1.2. |
TLDRI'm running into a similar issue using winget (v1.3.2091) on a clean install of Windows 11 Enterprise (v10.0.22000 N/A Build 22000). It looks like it is missing the Microsoft.Winget.Source dependency. Anyone know where to get it from? I have tried restarting the VM after installing WinGet and that didn't change anything. DetailsThis is the first command I execute after a clean install on a Windows 11 Enterprise VM on Azure, right after running the @cdhunt script: Console Output:
Digging into the log in ..\LocalState\DiagOutputDir and I found this:
Then later in the log I see this error:
What is odd is that this same exact response doesn't happen the second time. When I retry the same command line I receive the following Console Output now:
But the errors in the log look nearly identical:
And later in the log:
Notes
|
I found where to get it from in the WinGet log file. Looking at the logs it looks like it downloads it but cannot install it. I installed the Microsoft.Winget.Source app with the following: Invoke-WebRequest 'https://cdn.winget.microsoft.com/cache/source.msix' -OutFile 'c:\downloads\Microsoft.Winget.Source.msix' -UseBasicParsing
Push-Location 'c:\downloads';
Add-AppxPackage -Path 'Microsoft.Winget.Source.msix';
Pop-Location; Note: These results are preliminary! When I went back to look at what WinGet packages were installed I saw more than what I had installed. So I don't know if Windows 11 fixed this for me so it could do its own installs. Looks like I'll need to spin up another VM in Azure to test this on. |
The winget.ps1 script is currently not working. Microsoft is still doing work on this front so I'm going to wait until the dust settles here. If you need non-interactive installation of WinGet now then see here: https://github.com/asheroto/winget-installer/blob/master/winget-install.ps1 WinGet GitHub issues to track: microsoft/winget-cli#401 microsoft/winget-cli#2434 Also, perhaps MSIX Core so we can get Windows 7 support: https://learn.microsoft.com/en-us/windows/msix/msix-core/msixcore However, that's only MSIX, MS isn't targeting WinGet for below Windows 10 1809 (but maybe someone will build a small compatability layer): microsoft/winget-cli#1686 (comment)
The We've also been looking to update the dependency to Microsoft.UI.Xaml 2.8 from 2.7 in WinGet: |
We've provided documentation for installing the App Installer and its dependencies over at Microsoft Learn. |
Brief description of your issue
I would like to bootstrap WinGet and several WinGet packages on new Win10 systems.
What is the correct approach that handles dependencies appropriately and does not require user interaction?
This is what I'm using and it will break as soon as the dependency versions change.
It's also not possible to install MS Store applications because of a interactive license acceptance prompt that does not honor the--accept-source-agreements
argument.The text was updated successfully, but these errors were encountered: