You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit f583db4
Browse filesBrowse the repository at this point in the historyBrowse files
|`RegistrationsBaseUrl` (3.6.0 → 3.4.0 → 3.0.0-rc → 3.0.0-beta → unversioned) | package metadata, listed/unlisted checks; versions, `.nupkg` URLs and metadata when there is no `PackageBaseAddress`|
80
80
81
81
A feed needs `PackageBaseAddress` or `RegistrationsBaseUrl` to be usable. If it advertises no
82
82
`SearchQueryService` — or its search returns nothing — search degrades to an exact
83
83
package-id lookup against the flat container. Flat-container version lists include unlisted
84
84
versions, so an update candidate is confirmed against its registration leaf before being
85
-
surfaced.
85
+
surfaced. A version index answering 404 means the package is not on that feed, not a failed
86
+
check, since .NET Tool asks every configured feed about every installed tool.
87
+
88
+
A registration-only feed (JFrog Artifactory serves no flat container) is read through its
89
+
registration index instead: versions come from its pages, fetching only the pages above the
90
+
installed version during an update check; the `.nupkg` URL comes from the registration leaf;
91
+
and metadata comes from the version's page entry when the leaf carries no `catalogEntry`.
92
+
None of this runs for a feed that has a flat container.
93
+
94
+
On V2, Artifactory answers `GetUpdates()` with nothing unless `includeAllVersions` is true, and
95
+
then truncates the list at 100 without a next link. So when every `GetUpdates()` batch of a
96
+
source comes back empty, one `includeAllVersions=true` request tells "nothing is newer" (still
97
+
empty: stop there) from "this server ignores the request", in which case each installed package
98
+
is looked up with `FindPackagesById()?$filter=IsLatestVersion` (`IsAbsoluteLatestVersion` with
99
+
pre-releases). V2 version lists follow `next` links, up to 50 pages.
86
100
87
101
### Fallback behaviour
88
102
@@ -92,9 +106,24 @@ retried against a fabricated V2 endpoint. V2-only feeds never enter the V3 path
92
106
93
107
### Which feed is which
94
108
95
-
-**.NET Tool** — `https://api.nuget.org/v3/index.json`. Safe to repoint because the manager
96
-
does not support custom sources and never passes the source URL to the `dotnet` CLI. Also
97
-
filters search on `packageType=DotnetTool`.
109
+
-**.NET Tool** — the enabled sources of the user's NuGet configuration, read (not edited) by
110
+
`DotNetSourceHelper` from `dotnet nuget list source --format Detailed` run in the user profile
111
+
with `DOTNET_CLI_UI_LANGUAGE=en`, so `disabledPackageSources` and the whole config hierarchy
112
+
apply as they do for `dotnet tool install`. Output it cannot read, or a failed command, falls
113
+
back to nuget.org. The files from `dotnet nuget config paths` supply `packageSourceMapping`
114
+
(an installed package is never sent to a feed the mapping does not allow for its id) and basic
115
+
`packageSourceCredentials` (clear text, or DPAPI-encrypted with the `NuGet` entropy on
116
+
Windows; a closer file's entry wins even when it cannot be used, such as one restricted to
117
+
`negotiate`). `NuGetFeedCredentials` keys each credential by its feed, since feeds sharing a
118
+
server (Azure Artifacts) carry different ones, and sends it only on requests made for that
119
+
feed and only to that feed's own server; every request site passes the feed it belongs to.
120
+
The snapshot is kept until a config file's write time changes, or for ten minutes. Updates are
121
+
checked on every enabled feed and the newest wins; the feed at nuget.org's URL is always
122
+
`DefaultSource`, whatever its key. `dotnet tool list` names no feed, so installed tools sit
123
+
under nuget.org when it is enabled, else the first feed, and `InstalledPackagesKeepTheirSource`
124
+
is false so loaders match them to updates and search results from any feed by id. Search
125
+
filters on `packageType=DotnetTool` on V3 feeds and local folders; V2 feeds have no such
126
+
filter and may list libraries. Icons and installer downloads do not carry credentials.
98
127
-**PowerShell / PowerShell 7** — sources are enumerated from `Get-PSRepository` (or
99
128
`Get-PSResourceRepository` on PowerShell 7), so the URL is CLI-owned identity
100
129
(`PowerShellSourceHelper` compares it literally to choose `Register-PSRepository -Default`)
|`manager list`| None | None | Lists managers and their automation-relevant capability flags. |
205
-
|`manager maintenance`|`--manager <id>`| None | Returns maintenance metadata for one manager. |
204
+
|`manager list`| None | None | Lists managers, their automation-relevant capability flags and their listing health (see below). |
205
+
|`manager maintenance`|`--manager <id>`| None | Returns maintenance metadata for one manager, including the actions it supports in `supportedActions` and its listing health. |
206
206
|`manager reload`|`--manager <id>`| None | Reloads one manager. |
207
207
|`manager set-executable`|`--manager <id>`, `--path <path>`| None | Sets a custom executable override, then reloads the manager. |
208
208
|`manager clear-executable`|`--manager <id>`| None | Clears the custom executable override, then reloads the manager. |
|`manager action`|`--manager <id>`, `--action <action>`|`--confirm`| Runs one of the actions the manager lists in `supportedActions`. Every action except `reload` requires `--confirm`. |
210
210
|`manager enable`|`--manager <id>`| None | Enables the manager. |
211
211
|`manager disable`|`--manager <id>`| None | Disables the manager. |
212
212
|`manager notifications enable`|`--manager <id>`| None | Enables update notifications for the manager. |
213
213
|`manager notifications disable`|`--manager <id>`| None | Disables update notifications for the manager. |
214
214
215
+
Maintenance actions, as `manager action --action` accepts them:
216
+
217
+
| Action | Managers | Notes |
218
+
| --- | --- | --- |
219
+
|`reload`| All | Looks for the manager again and reloads its configuration. |
220
+
|`stop-stuck-listings`| All | Kills the processes of any search, package listing or maintenance command the manager is still running. |
221
+
|`repair-winget`| WinGet (Windows) | Clears WinGet's temp folder, resets its sources, repairs it through `Microsoft.WinGet.Client` and resets App Installer. Elevated. |
|`install-scoop`, `uninstall-scoop`| Scoop (Windows) | Installs Scoop (elevated), or removes it with every package it installed. |
224
+
|`cleanup-scoop`| Scoop (Windows) | Removes old app versions, per user and machine-wide (the machine-wide half is elevated), then empties Scoop's download cache, which both scopes share. |
225
+
|`clear-cache`| Chocolatey, Pip, Npm, Bun, .NET Tool, Homebrew | Runs the manager's own cache-cleaning command. |
226
+
227
+
Actions that need the manager's own executable are only listed once the manager has been found. `repair-winget`, `reset-sources` and `install-scoop` are listed even when it has not. A maintenance command that runs for more than 15 minutes is stopped and reported as failed.
228
+
229
+
#### Manager health
230
+
231
+
`manager list` and `manager maintenance` include a `health` object built from a record UniGetUI keeps
232
+
for each manager across restarts, in `ManagerHealth.json` in its data folder:
|`needsAttention`|`true` when the app shows its health banner: a malfunction, or a listing that failed at least twice in a row with its last failure in the past 24 hours. For WinGet, Apt, Dnf and Pacman a single failed installed listing is enough. |
238
+
|`failingListing`|`search`, `installed` or `updates`: the listing that failed most recently, or `installed` for a malfunction. |
239
+
|`reason`, `consecutiveFailures`| The failing listing's last error and how many times in a row it failed. |
240
+
|`search`, `installed`, `updates`| Per listing: `lastSuccessUtc`, `lastFailureUtc`, `lastFailureReason`, `lastFailureWasTimeout`, `consecutiveFailures`, `lastPackageCount`, `lastFastRepairUtc`, `lastFastRepairReason` (a first attempt that failed and was retried) and `recentDurationsMs` (the last ten). |
241
+
242
+
A manager is `malfunctioning` when it is ready, its installed listing succeeded and returned no package
243
+
at all, and a working installation of it always lists something (WinGet, Apt, Dnf and Pacman). The
244
+
`DisableWinGetMalfunctionDetector` setting still turns this off for WinGet.
0 commit comments