Winget Just Download [WORK]
Daría Davino
What continually suprises me is that using winget for updates is often faster than the in-app (or in-application) update facility itself. Visual Studio 2022 made an interesting case in point just now, when it updated that hefty environment (nearly 400 MB to start it going, and over 150 packages as the process worked to completion). It finished in well under 2 minutes on this aging desktop PC (i7 SkyLake, 32 GB RAM, 500 GB Gen 2 PCIe SSD).
But something about it worries me: a lot of software has all kinds of user-hostile defaults selected in the installer, everything from "enable telemetry" to "install this extra, unwanted malware as well". Whenever I install any software manually, I take great care to disable all of that. But what does winget do?
Sadly, since this appears to be true, winget is useless to me. Way too many softwares are way too eager to re-enable user-hostile options when you update (which almost always runs the whole installer again).
First of all, you misunderstand what winget is. It's a package manager that wants to be similar to package managers from Linux. Thus it can install packages from many sources. Of course, if your choice of a source is not trusted, then winget can't do much about the security of your device. But let's assume we're talking about official sources.
It seems like submissions are scanned and the results are viewed bya moderator. You either trust the process or not, but it seemsthat winget doesn't trust anything that does not go throughthe process.
I didn't find information about installing via winget (which is working). It seems reasonable to include instruction on github or in Unofficial alternative Joplin distributions. But I don't know which one is correct place. Could you clear it up?
I'm unsure whether it makes sense to say Winget is a third party distribution. It downloads the official .exe and simply runs it with the /quiet flag to supress the installation UI; it'd be like arguing the Linux AppImage is unofficial just because you use a script to acquire it, except that the AppImage installer script is actually handling a lot more than Winget does.
I think the distinction there is more the distribution method and who maintains it. The same argument could be made for the AUR .appimage which, as far as I know, is basically the same thing as this.
It is still a good idea to list it because there is no official channel that updates the winget repo so it is entirely possible that it becomes stale if nobody maintains it; leading to issues like mismatched versions between mobile and desktop for which people come looking for support. Not to mention if there are any issues during the install procedure itself as a result of what has been put into those manifests.
I can't really propose any actual changes, I suppose trying to be rational, the wiki is fine as is really. But I do think calling Winget a package manager is extremely misleading even if it is the official wording, it implies there's actually Winget packages; there isn't, it's just the normal app packages which it happens to manage.
When it comes to support, unless the issue is obvious due to the distribution method (e.g. can't install Joplin from winget because it gives x error when I enter this command) I don't think anyone gets turned away, most of the support given tends to be from community members without any official affiliation anyway and it isn't like there is some kind of call logging/ticketing system in place.
As of now, the steps for updating are 1) running op update 2) downloading the new update 3) unzipping the file 4) moving op.exe to C:\Program Files\1Password CLI 5) deleting the downloaded files and 6) running op update to verify the update. I want to cut that down to just run winget upgrade "1Password CLI".
In the installation instructions I see that it's available as a package through winget. I searched the forum and found some threads with feature requests for making the application available on winget, but the threads I looked at mentioned that it was on the roadmap and that packages that already were available on winget were community maintained. Is that still the case or is the package managed by 1Password now since that installation method is listed in the docs?
So far I've used the manual installation method for installing and updating the application. Can I "switch" to the winget package easily and will it just take over from my manual install, or are there any caveats to consider? For example, I have my own account and a service account configured to use the current 1Password CLI installation. The service account is used in conjunction with some scripts that run on a schedule. Will the accounts and scripts continue to work or will I have to configure everything from scratch again?
I ran the command winget install 1password-cli and it installed just fine and my scheduled scripts continues to work, so I can confirm that it was as easy as that to switch from manual installation to winget. This might be different if you've installed 1Password CLI with the manual method and placed the op.exe in another location than the default C:\Program Files\1Password CLI.
Running this executable directly works just fine under SYSTEM. I created a simple script which when packaged as a Win32App, can be used to deploy any package located in the WinGet public repository automatically to Intune enrolled endpoints.
Windows Package Manager by default creates log files when executing commands. These logs contain information that can aid in debugging issues with WinGet. There is no maximum size for the log files. They are typically only a few KB in size. When the number of log files in the directory exceeds 100, the oldest log files will begin being deleted. There is no time-based removal of logs and these settings are not configurable. If you have reached the 100 file log capacity, just move any WinGet logs that you wish to preserve into a different directory.
The winget tool returns exit codes to indicate success or failure of the command. Find a table of exit codes and their meanings in the "Return codes" file of the Windows Package Manager Client repository.
Thanks so much for stopping by. Since you're here, I'm assuming you love middle-grade fiction. Me, too. I was blessed with parents who read to me from the time I was very young, but it wasn't until around fourth grade that I fell deeply, madly in love with books. Charlotte's Web, Where the Red Fern Grows, and a little later, The Outsiders, became three of my favorites and still hold a place of honor on my bookshelf today. I especially loved books about normal kids who faced tough situations and had a love for animals. So guess what type of books I most love to write? Yep, you figured it out ... books just like that.
Yea, I wrote a script just for using winget so that I don't have to install the app's in the image that way my image is smaller and I get the most up to date apps each time a systems imaged. Initially I used a scheduled task that ran on first login to deploy the script which works just fine for installing. If you're just looking to update installed apps you can use winget upgrade. You just need to update the name, ID, and type in the script below which you can find by running winget search "appname". I added calc as an example of how to install an msstore app as well in case the app youre trying to install isnt on the winget repo.
Once you use the Installer script in my first post to install the apps via winget you just need to schedule a task to run however frequently youd like the PC's to update using the command below which will run the update command as System.
The gorgeous Jennifer Winget shared an adorable photograph on the social media. Moreover, while sharing the pic, she posted a rather cryptic message and stated that her dreams had just become a reality.
As shown below, I am using almost the same script as I used when deploying Applications with Winget. In this detection script, I am just trying to find the Winget.exe file in the latest DesktopAppInstaller folder
Thanks for the quick reply! So the script does in fact create the task but when run nothing actually happens. Nothing Updates when trying to check winget list afterwards. I have tried using system as well as the logged in user to run it as.
I also am having big problems with running MSstore apps and Winget in the system context. Same error as above. Not apparent reported issue on the Git either.
Works just fine tough with the Winget repo.
The Romanitho script is an interesting solution with some caveats, but I guess they are more related to winget itself than the update task.
What I found is that it might happen that an update triggers a client reboot, and when this happens, the clients restarts without any warning whatsoever. Kind of a brutal situation in a production environment. :\
I have previously worked around this to pipeline the outpout to Out-Null or using a Start-Proces -Wait parameter. What would you suggest making sure the script waits to finish until the MSIX bundle is installed and winget.exe is available?
I think winget just needs to add ZIP support. I'm already publishing numerous package types, with long builds times and gigabytes to upload. It's already a lot to keep track of. All they have to do is unzip the EXE and do what they'd normally do for an EXE.
df19127ead