winget-cli: Error 1603 -- easy work-around and easy fix.
Brief description of your issue
Steps to reproduce
I tried installing Adobe.brackets.
It failed with 1603
Run in admin shell and it works.
Before I get into it there are two problems with easy fixes
-
Instead of error 1603 give an actionable message. This is such a fundamental point that I shouldn’t have to say it for the umpteenth time.
-
The fix was to run it with privilege. Tell me that in the error message and, better, offer, to do it automatically.
Expected behavior
Install brackets
Actual behavior
Error 1603
Environment
Powershell
[winget --info]
Windows Package Manager version V0.1.41331 Preview
Windows: Windows.Desktop version 1609
Package: Microsoft.DesktopAppInstaller version
Any other software?
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 15
- Comments: 20 (7 by maintainers)
I don’t know if it helps, but I am experiencing the same issue with LibreOffice. If I download and install it manually, it works perfectly fine.
This error message is coming from the MSI installer, and not the Windows Package Manager. I’ll convert this issue into a Feature so we can add a better error explanations when we get error 1603 from MSI installers.
Running PowerShell (Admin) and using -i flag solved my problem
winget install -i <name>I was facing issues with LibreOffice and VirtualBox Installer failed with exit code: 1603 [Running PowerShell (Admin) solved] Then, Installer failed with exit code: 3010 [Running in -i solved]
It’s been so long that I forgot what adobe.brackets is but it does seem to install. But figured I’d give it a try to just to hukmor you since, obviously, the problem has been fixed … or has it?
This issue is complex, as there can be many causes of error 1603. I was receiving this in an automation when installing Adobe.Acrobat.Reader.64-bit. I was auto-installing each available version into a subdirectory named after the ID of the application. I was using “–override” to specify the install directory and getting 1603s. All permissions on path were wide open.
/msi /qn INSTALLDIR=C:\SamplePath\Adobe.Acrobat.Reader.64-bit\22.001.20142 /norestart EULA_ACCEPT=YESI pre-created the Adobe.Acrobat.Reader.64-bit root directory and the errors went away. Feels like could be a bug within the Adobe installer when accepting an override path via winget, failing to create the path before the last segment. If using override, try pre-creating the root dir path.According to the documentation
but it doesn’t work now.
For install the application in the current cmd session you can use interactive mode (option -i) or third-party sudo command