Winget: The Misery Has a Name

Winget: The Misery Has a Name

This is a text I had to write. Perhaps someone at Microsoft will read it and go to the bedroom in Seattle and wake someone up - I don’t know who. So will Microsoft wake up?

As far as I am concerned, Winget is no longer as repulsive as it was when it first appeared. It has picked up a lot of good things. I mean, it’s still an ordeal compared to Scoop, but less so, and yes, the technical problems still exist, mostly related to a proper “uninstall” option for packages.

Personally, I think that the company Microsoft has gone down the drain. I beg Bill Gates to let his foundation’s staff work in Africa for a while while he goes back to Seattle and “fixes” the people who work there now, because I don’t know what they’re doing.

I’m aware that the Azure cloud is now the main story at Microsoft, but I think they should not forget their roots and how they started, because if they forget, they soon could be “blown away”. The way how Apple started with their M1 and M2 computers, in 5 to 10 years it could be “bye, bye” to Windows". But the management team in Seattle doesn’t seem to care. C’est la vie!

Issues, Unsolved

Lack of regular uninstall

I’m not going to bother with this at the moment, as it’s the only drawback that’s not currently and easily fixable. In the beginning, this was my biggest functional problem. The fact that there was no way to ‘uninstall’ or ‘update’ packages. However, it became completely irrelevant to me as I realised that everything around Winget is a nonsensical amateurism.

The years went by, and… Well, it seems that in 2023 they finally had an “advanced” uninstall option for packages. Although I haven’t checked how it works, and I’m afraid to see if it works at all, it promises to do even a rudimentary “purge” for a portable app. At least that’s what it says. So to remove an app and its traces, I should just do winget uninstall --purge app.

Limited to Installing One App at a Time

In the style of “everyone does it one way and we’ll do it another”, Winget has the limitation that in one command it can only perform an operation on a single package. Thus, there is no way to write a single command that installs multiple applications, you must create several separate commands, one for each package.

Uncertain about Self-updating

I’m not sure if it has the ability to update itself. As I mostly install it via Scoop or manually, rarely via the Microsoft Store, I hope it has mastered the “magic” of self-updating and has finally come at least a little closer to other package managers.

Not bundled with Windows

Isn’t a package manager one of the most important features of an operating system? It’s hard to believe that it’s not included with Windows. Not only is it critical, but it is used for the installation of applications, i.e. it is one of the **very first **applications you need when setting up a new computer. This is really a ridiculous irrationality.

Does not install from the command line

You would think that a tool whose primary place of existence is the command line, in other words one that does not have a GUI, would assume that this tool could be installed within the same environment. Not with Microsoft. In the hands of their experts, it is not. Indeed, they have concluded that the best way to install it is from the Microsoft Store GUI environment and, of course, to do so “incognito”, that is, under a different name. Incidentally, the Microsoft Store requires you to have an account and login. An extra bit of work for the owner of the computer, of course.

Admittedly, it is possible to install Winget from the PowerShell command line. But the process is really much too complicated. Am I wrong here? Maybe there’s a simpler way?

Winget or App Installer, the question remains

Lets have a look at a confused user. Having just noticed that the Winget command is missing, he correctly assumes that he can install from the Microsoft Store. So he typed winget. And got - nothing. This is because the name of the application is not “Winget” but “App Installer”. I don’t understand, my goodness. Typing “winget” gets some strange applications with similar names, but even to the naive user it’s obvious that none of them is the real Winget app.

Five minutes later, after a bit of googling, the user, or I, will find my way around. But it’s pointless. Without searching the Internet for help, I can’t even get past the first few steps.

Surely, no Product Owners Work at Microsoft Anymore

You won’t get this! Our application is called Winget, I would like to remind the “geniuses” at Microsoft. This is because there is no mention of the word “Winget” anywhere during the installation of the Winget application from the Microsoft Store.

Apart from the aforementioned and controversial name “App Installer”, which is mentioned only once and quite small, there is mention of an application “My Employees”, “Install My Employees? Contoso”.

It’s clear to me what these screenshots illustrate, but only after I’ve searched Google for “Contoso” and “My Employees”, just in case.

Not only that, but after I had installed a program called “App Installer”, the screen kept saying “Contoso” while I was waiting. By some bizarre turn of events, Microsoft expects the user to somehow deduce that the program is being run from the command line and that the command is “winget” and not “appinst” or “contoso”. This is such a charade.

Let me try it now that it’s finally installed

So, lucky me - or more accurately, our typical user - tries to launch the “App Installer” application. But it’s nowhere to be found. Since he has already read all the nonsense about Winget on the Internet, he looks for it in the Start menu. Maybe it’s a shortcut on the desktop. That would be so Microsoft.

But there is nothing, nowhere. So what have I installed? I don’t have anything to run. Let’s go back to Google and search some more.

There is No GUI for Discovering Packages

I mean there is, and it’s called Microsoft Store. But that’s not what I want. Obviously I find Microsoft Store not a good fit for discovering packages, and I always unconsciously go to winget.run site. First, not all packages that are available to Winget are listed in Store, and second - it is 100 times easier for me to just copy-paste the command to install something, then to remember.

Good news is they at least made that site right, as expected from such huge company. Wait, but what’s that, now…

The Winget.run Site Is Not Owned by Microsoft

It turns out that Winget site wasn’t created by Microsoft, but by a company called Feinwaru Software. Is it really safe to listen to what they provide on that site.

It’s true that I only use the site for copy-pasting, but I’m guessing that it can be exploited in some way. This amazing fact about site isn’t sane at all, as this is the site that I and other users most often go to, because it’s easy to remember and, in the end, it does its job perfectly.

Not the same Packages on Store and on Winget

I’ve finally reconciled and everything came together in me, and I somehow got used to this mess. So let’s conclude what I know so far.

A program called Winget, which is invoked from the command line, I installed under another name, “App Installer,” and that was done by showing screens of third-party applications “Contoso or whatever.” Ok, I’ve got that. Then when looking for packages I’m consulting a site that’s properly named, but has no connection with Microsoft whatsoever.

Alright, let’s accept that as logical. So “filled” with new knowledge, I bravely install the PowerToys application with the command winget install -e --id Microsoft.PowerToys. Bad move that was.

Baffling Parameters

I simply do not comprehend this. Instead of, like in the rest of the sane world, i can install a package with, for example winget install PowerToys, the “geniuses” at Microsoft have found some sort of justification as to why the primary and fundamental operation of this tool must (I mean install, not pissing users) have the following baffling elements:

  • an option with just one dash (-) which is probably unneeded, but since the computer can explode if you skip it, then you must tirelessly tap it your whole life until death

  • a second option with two dashes (--) for the reasons unknown to all. Of course, you need to add a parameter, even though the most important value follows it without which there is no command. Must I then specify what the main parameter is? It’s like searching for files by name on Linux and having to mention that it’s searching for files by name… Ah, yes, find . -name reminds me that there are also “neglected” decisions in other ecosystems.

  • the third problem is that the parameter is named “id” and what follows it looks like the application name to me. But okay.

  • oh, no, that is not an application name, we won’t make it that easy. Then user could assume by themself how some application is installed, and that we won’t allow. We will put here some strange construction that you will never be able to “guess.”. For example, let’s make it so that to install “Spotify” you actually have to type “Spotify.Spotify,” just like that, to entertain ourselves in Redmond.

  • And sometimes I’m noticing some unique ID instead that package “name” there. Well, that you will definitely never remember. Just to show you who’s boss.

Discovering the Secret ID is… a Secret!

It is impossible to find package ID from the Desktop version of Microsoft Store, but you can see it on Microsoft Store website on the internet, as the ID will appear as the last part of the URL. So in the case of our “Spotify.Spotify” application, that ID is “9NCBCSZSJRSB”. What a trick and wonder!.

You can also discover that package ID number, similar to the website, by searching the Winget database from the command line. For example, for “PowerToys” try typing:

winget search PowerToys

And you’ll get the famous ID as value “XP89DCGQ3K6VLD”. And why this ID can be important?

Different Versions in Different Repositories

The question now looming in the air is why we even have both the ID, the real ID, and the “name” ID in textual format.

Which Version to Install?

How to determine which version to install? My answer is always to install from the Microsoft Store, as I have once been burned.

That happened when I installed the PowerToys tools with winget install -e --id Microsoft.PowerToys and I acquired version 0.66. Then, by sheer coincidence, struggling with the torture experience known as Winget, I noticed that version 0.67 was available in the Microsoft Store.

This is when I realized that these are completely separate repositories, so one must always be “better,” in our case it is usualy the Official Store. I mean, finally we have something expected of this whole story. But there are consequences…

When I think more about this last thought and reflect on it a little deeper, this means that I should not install applications by name, never, but always by this encrypted ID. And that in turn means that I cannot do anything “off the top of my head”, but I must constantly consult my computer and discover the proper ID values for each package I want to install.

And I can’t just visit Store URL for those ID’s as it happens that some applications are not there in Store, but are available in the Winget repository. Such an example is “Authy”, and there are surely many more. That means, the only source of truth about whether an application exists is the aforementioned command winget search in order to find out how to install the application.

The valid conclusion is that the “simple” installation is not so simple anymore, at all. In the Microsoft case it takes the form of a command that looks like the following example. I will provide an example of installing the Firefox browser.

winget search Firefox
winget install -e --id 9NZVDKPMR9RD

In the first step, I decided which value of ID it is, so that the application comes from the Store, and in the second command, I actually did install Firefox. So I finally succeeded in installing the first application. Woow!

Competition as the Most Elegant Way to Setup Winget

I must mention the ultimate shame related to the installation of Winget. Indeed, I am confident that the most efficient way for the user to install Winget is to run scoop install winget. Even if the user first have to set up Scoop only for that purpose, I believe it’s still faster and simpler than the installation suggested by Microsoft.

Installing Winget

Through Scoop

Yes, it is absurd, but this is undoubtedly the easiest way to install Winget. It’s perfectly fine with me, as I only use Winget for what’s not available through Scoop or what causes problems there, such as PowerToys.

scoop install winget

Via PowerShell

I simply cannot believe that this is the “most efficient” way to install Winget through PowerShell. I must be missing something, and there must be a much shorter and simpler version, right?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# get latest download url
$URL = "https://api.github.com/repos/microsoft/winget-cli/releases/latest"
$URL = (Invoke-WebRequest -Uri $URL).Content | ConvertFrom-Json |
        Select-Object -ExpandProperty "assets" |
        Where-Object "browser_download_url" -Match '.msixbundle' |
        Select-Object -ExpandProperty "browser_download_url"

# download
Invoke-WebRequest -Uri $URL -OutFile "Setup.msix" -UseBasicParsing

# install
Add-AppxPackage -Path "Setup.msix"

# delete file
Remove-Item "Setup.msix"

Instead of complaining

At the end of the day, it is clear that I am neither an expert nor a believer in this creature known as the Winget. At one time I dabbled with Chocolatey. Then I realised how much it was burdened by the NuGet travails, which in turn were spurred on by the company with the initials MS. Eventually, the beautiful and elegant Scoop appeared.

Every command I typed was in a logical place and had a logical response. No unnecessary dashes or slashes, no double dashes or single dashes, no dilemma between the ID name and the app name. None of the above. Everything just worked, in the most logical and expected manner.

Come on, gentlemen of Microsoft. Buy this guy Luke Sampson and his company Scoop if he wants to sell. If not, then at least swallow a cube of chocolate, also known as Chocolatey. If Balmer were still around, it would have been a done deal long ago. What are you waiting for? You had 30 years to make a decent package manager. You failed. Satya Nadella made a good start with smart acquisitions, but now his mind is on the Azure cloud. And he is probably right.

Thank you for reading

Intriguing Addendums

Winstall Can Forge Sets for Winget’s Installation

Winstall is an imaginative web application that generates a compilation of batch-installation commands from Winget applications of your choosing, facilitated by a user-friendly interface. It proves itself valuable for streamlining the setup of Windows.

WingetUI, a GUI that Harmonizes Package Managers

WingetUI is a hybrid tool with a groundbreaking concept of pioneering a new segment that amalgamates Scoop and Winget.

Specifically, marticliment/WingetUI is a graphical user interface for both Winget and Scoop, installable via scoop. It’s worth mentioning that its startup time, particularly when refreshing the database of applications, is relatively prolonged, and that’s main reason I won’t use it.


Ovo je neki propali stari pokušaj:

PowerShell Gallery is new to me? The PowerShell Gallery

PackageManagement (aka OneGet) is a package manager for Windows

OneGet/oneget ethanbergstrom/winget jianyunt/ChocolateyGet OneGet/MicrosoftDockerProvider

Install-PackageProvider ChocolateyGet -Force Install-PackageProvider WinGet -Force

Find-Package Mozilla.Firefox -Provider WinGet -Detailed Find-Package -Provider ChocolateyGet -Name nodejs

To remove:

(Get-PackageProvider NuGet).ProviderPath (Get-PackageProvider ChocolateyGet).ProviderPath

Remove-Item -Force “C:\Program Files\PackageManagement\ProviderAssemblies\nuget\2.8.5.208\Microsoft.PackageManagement.NuGetProvider.dll”

Or in one line: (Get-PackageProvider|where-object{$.name -eq “NuGet”}).ProviderPath|Remove-Item -force (Get-PackageProvider|where-object{$.name -eq “ChocolateyGet”}).ProviderPath|Remove-Item -force

Restart-Computer

(Get-PackageProvider NuGet).ProviderPath

Remove-Item -Force “C:\Program Files\WindowsPowerShell\Modules\PackageManagement\1.4.8.1\fullclr\Microsoft.PackageManagement.NuGetProvider.dll”

date 15. Dec 2022 | modified 10. Jun 2024
filename: Windows » Package Managers » Winget