Open bandizsolt opened 10 months ago
Could the issue be that when running winget in system context, it cannot see the correct IDs for the installed programs? As shown in the attached capture, the installed software seems to have incorrect IDs in the system context.
It only fails to display the correct ID under the system and user contexts, it shows correctly for the admin user.
@stephengillie Could you please point me in the right direction on how to investigate what might be causing this?
Hi @bandizsolt,
Unfortunately I'm not well-informed on the specific impacts of using the SYSTEM
context, and will defer to @Trenly and @denelon.
Hi, @stephengillie, thank you very much, I just need a little guidance on where to start so I know where to begin. It would be a bit much to sift through the entire source code to find a solution for this.
I searched Issues for SYSTEM
and ame across this:
When running as the SYSTEM user, any application information stored in a specific user profile isn’t accessible to WinGet. When looking for applications that are installed, WinGet will check the registry for application information in both the Local Machine and the current user. When running as SYSTEM, any applications installed in a specific user scope won’t be visible to SYSTEM as their information is under that specific users UID and not the SYSTEM users UID
The package manager software reads the Windows Registry (and other sources such as its installed.db?), and compares this to an XML of manifest data, to detect other installed software. These 2 outputs you mentioend do look like the application is reading the wrong line of data from somewhere such as the Edit: manifest file.
user
scope packages not being visible, it's machine
scope packages, and that Issue states that machine
scope should still be visible.Edit continued:
The GUID provided above matches the x64
ProductCode
from version 7.1.2
of Cyanfish.NAPS2.
The other output provided above matches the PackageName
for eloston.ungoogled-chromium.
If I understand correctly, then winget reads the installed programs from the Windows registry and compiles a list from that. Afterward, somehow it tries to search by name, and if it finds a match, it downloads the corresponding manifest file, from which it extracts information such as whether there is a new version and where to download it from. Please correct me if I'm misunderstanding.
For example, when using the winget list command, does it retrieve all installed programs from the registry, search for them in the winget and msstore sources, download the manifest files, and list them?
I tried to find this installed.db file and got 4 hits, but all of them are empty, with no values. So, it seems it only retrieves data from the Windows registry for installed applications and then creates a list.?
For this Product code: {E84C60AF-70D3-4588-A8EE-A2FC1A2AB71B}, I found 9 hits in the Windows registry, and I'm attaching two of them as screenshots, where some data is visible.
I've also figured out that these values are in the manifest files, but I still don't know how it works winget in the background with these.
Thank you very much for your efforts!
The Publish pipeline takes our repo's /manifests
contents, and rewrites this into an XML file, which is compressed into source.msix, and put onto a host for our CDN to distribute. Then, running 'winget list" has the client download this MSIX and decompress it, to use as a data source. This data is compared to data under certain Registry paths within HKLM
and HKCU
, and matching results returned.
Brief description of your issue
I installed ungoogled chromium using the following command:
or NAPS2 with:
Now, when I try to update using winget running in the system context, it doesn't recognize these applications, and as a result, it doesn't update them.
Now I don't know how to trace this back if it's an issue with the installation file, to understand what the problem might be.
Using this program (https://github.com/Romanitho/Winget-AutoUpdate), I've come to the point where winget doesn't recognize these software applications in the system context (in this issue are the details https://github.com/Romanitho/Winget-AutoUpdate/issues/362). However, it's also possible that winget doesn't recognize them because something goes wrong during the installation.
Steps to reproduce
Install ungoogled chromium using the following command:
Alternatively, install NAPS2 with:
When attempting to update using winget in the system context, it fails to recognize these applications (tested with winget export), resulting in an inability to update them.
Expected behavior
The ability to update these applications in the system context.
Actual behavior
It cannot be updated with winget when using it in the system context.
Environment