Requires updating source every time

[github-account1111]

Brief description of your issue

Sort of a continuation of #2696 because ever since working that one time in my last comment it has not fetched an upgrade for a single package. This was not the case about a year ago, so I'm either missing something, or this is a newly introduced bug or a design flaw. The upgrade command is essentially useless because it will say No installed package found matching input criteria. until source update / source reset --force is run. What is the point of checking for upgrades without updating the local source copy? Shouldn't winget check the actual source so long as there is internet connection?

Steps to reproduce

Run winget upgrade / winget upgrade --all.

Expected behavior

Packages get upgraded to the latest available versions according to their latest manifests.

Actual behavior

Packages seem to get checked against the local copy of the manifests only which is useless and will continue to show there are no upgrades.

Environment

> winget --info
Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

[Trenly]

Out of curiosity, can you post the contents of your settings file? It can be opened with winget settings? Also, can you provide the log file from winget upgrade --verbose-logs?

[github-account1111]

Settings:

{
    "$schema": "https://aka.ms/winget-settings.schema.json"
    // For documentation on these settings, see: https://aka.ms/winget-settings
    // "source": {
    //    "autoUpdateIntervalInMinutes": 5
    // },
}

winget upgrade --verbose-logs

[denelon]

@github-acount1111 you might try switching to the winint downloader:

https://learn.microsoft.com/windows/package-manager/winget/settings#downloader

Test with "wininet" instead of "do".

[github-account1111]

Switching to wininet hasn't helped.

Also I misreported that source update / reset --force fix this. They don't.

It's back to square one. Either the CDN issue is back, or it's a different issue that manifests itself in the same way.

[denelon]

@github-account1111 what results do you get from winget list winget?

"Windows Package Manager Source (winget)" is the PreIndexed source package used by WinGet for the community repository.

[github-account1111]

> winget list winget
Name                                    Id                                    Version
------------------------------------------------------------------------------------------------
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2022.1129.2104.261

[denelon]

That looks quite old. Try manually installing: https://cdn.winget.microsoft.com/cache/source.msix

Then run winget list winget to see if the update actually worked correctly.

[github-account1111]

Yeah, that's literally when it worked for the first and last time, as I reported in this issue.

Running source.msix throws the following error:

[github-account1111]

Is this being looked at, at all?

Winget can't update packages, and millions of users are using outdated software as a result of this bug. Some of my apps are so old at this point they won't even open.

[denelon]

@github-account1111 which version of WinGet do you have on your system? The original message shows 1.4.10173 and I'm not able to reproduce the issue on my end. Are there any network or firewall rules that could be limiting network access?

Looking at lines 48-56 from the log it seems the package is landing on the "D:" drive.

Have you done something custom with your profile path or anything else similar to get the package to install in that location? I'm guessing that's part of what's happening.

[JohnMcPMS]

I would suggest removing the source package as I believe that something on the system is broken with it:

PowerShell> Get-AppxPackage Microsoft.Winget.Source | Remove-AppxPackage

We should put in some attempt to automatically do this after a failure to update the package.

[github-account1111]

1.4.10173 is still the version I'm using, yes. Maybe I should give a pre-release a try.

Nothing in my firewall rules that I have enabled or disabled explicitly - on my computer or the router.

Looking at lines 48-56 from the log it seems the package is landing on the "D:" drive.

Interesting. I have an O: partition on my SSD for media, a few games and portable apps. I also store some of scripts for a quick Windows setup on it, but it'd be weird if simply running a script from a different location meant the package gets installed on a non-system drive. I occasionally also connect external drives under M:, N: and P:. I guess any new device would default to D: (phone, thumb drive).

But no, I haven't installed anything outside of C: (at least not knowingly).

[github-account1111]

@JohnMcPMS ok the command went through without errors. The problem is I think it made it worse?

> winget upgrade
Failed when searching source; results will not be included: winget
No installed package found matching input criteria.

Is there something else that needs to be run after that command?

[JohnMcPMS]

Without the logs, I'm going to have to guess that while you have removed the old package from being visible, it has not resolved the issue with the Access Denied updating it. So you no longer have outdated data, you have no data.

If you use Feedback Hub (🪟 +F) to file an issue with the category "Developer Platform" -> "App Deployment" and collect a repro while attempting to install from https://cdn.winget.microsoft.com/cache/source.msix , then I can better see what exactly is failing and if it is known or not.