dotnet tool

ID

dotnet

Home page

https://learn.microsoft.com/dotnet/core/tools/global-tools

Version requirement

>= 8.0.400

Platforms

🐧 Linux · 🍎 macOS · 🪟 Windows

Operations

installed · search · install · upgrade · upgrade_all · remove

purl types

pkg:dotnet · pkg:nuget

CLI name

dotnet

Every call

dotnet tool <command>

Forced environment

DOTNET_CLI_TELEMETRY_OPTOUT=1 · DOTNET_CLI_UI_LANGUAGE=en-us · DOTNET_NOLOGO=1

Issues and PRs

📦 manager: dotnet

Source

meta_package_manager/managers/dotnet.py

.NET global tools, the CLI programs the .NET SDK installs from NuGet.

Every operation goes through the dotnet tool subcommand group, forced by DotNet.pre_args, and targets the user-wide scope with --global. Global tools land under ~/.dotnet/tools and are never shared between users, so no operation escalates: elevation is only ever needed for the separate --tool-path scenario, which this wrapper does not drive.

Documentation: .NET global tools.

Note

The listing and the search results are column tables whose headers are localized resource strings, translated into thirteen languages. Rather than match English literals, DotNet.extra_env pins the CLI language and both parsers key on the shape of the row: a package ID, two or more spaces, then a version starting with a digit. That skips the header, the dashed rule and any diagnostic prose the SDK prints above the table, such as the broken-tool warning of dotnet/sdk#4111.

Note

dotnet tool list also speaks JSON, through an undocumented --format json that landed in the 9.0.100 SDK (dotnet/sdk#37394). mpm deliberately parses the table instead: the three columns of the global listing are all whitespace-free, so nothing is gained, while keying on JSON would raise the floor past 8.0.4xx, the oldest SDK band still supported.

Caution

No outdated operation is declared: the SDK ships no way to compare installed tools against NuGet without mutating them. A spec for dotnet tool list --outdated was written by an SDK maintainer in dotnet/sdk#22853, which was then closed as not planned. upgrade --all is unaffected and maps to the native dotnet tool update --all.

Note

No cleanup either. The obvious candidate, dotnet nuget locals all --clear, empties the machine-wide NuGet package folder every .NET project restores against, so a tool-scoped cleanup would invalidate unrelated builds. Nothing clears only what the global tools pulled.

What mpm adds to dotnet

Through mpm, dotnet gains --exact and --extended search, to narrow to exact names or match descriptions.

Bigger still, mpm reaches across every manager at once: mpm installed and mpm outdated cover dotnet alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.

Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.

Your dotnet commands, in mpm

You already know dotnet: each operation maps one-to-one onto mpm, in an interface shared by every manager.

To…	With dotnet	With mpm
List what’s installed	dotnet list --global	mpm --dotnet installed
Search for a package	dotnet search format	mpm --dotnet search format
Install a package	dotnet install --global dotnetsay	mpm install pkg:dotnet/dotnetsay
Upgrade one package	dotnet update --global dotnetsay	mpm --dotnet upgrade dotnetsay
Upgrade everything	dotnet update --global --all	mpm --dotnet upgrade --all
Remove a package	dotnet uninstall --global dotnetsay	mpm remove pkg:dotnet/dotnetsay

Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.

Operations

Operation	Supported	Notes
installed	✓
outdated
orphans
search	✓	exact and extended search backfilled by mpm
install	✓
upgrade	✓
upgrade_all	✓
remove	✓
sync
cleanup
doctor

Selecting and configuring dotnet

Deselect dotnet for a single run with --no-dotnet, or persist the choice in your configuration:

[mpm]
dotnet = false

The arguments and environment variables listed in the box atop this page are forced on every dotnet call, so runs stay quiet, non-interactive and reproducible: the defaults you would set in CI anyway.

Keep it enabled but tune how mpm drives it with a per-manager override:

[mpm.managers.dotnet]
timeout = 900

mpm config-template dotnet prints every overridable attribute as a ready-to-paste block.

Recipes

A few jobs you would otherwise script around dotnet, one mpm command each:

• Snapshot and clone a machine: mpm --dotnet dump dotnet.toml, then mpm restore dotnet.toml on the next one.

• Export a compliance SBOM: mpm --dotnet sbom (CycloneDX by default, --spdx for SPDX).

Privilege escalation

mpm runs this manager as the current user and never prepends sudo by default. Flip the policy for its privileged operations with --sudo or the per-manager sudo override.

See privilege escalation for the full policy.

Cooldown

State of dotnet tool’s release-age gating, from the cooldown support table:

• Status: 🚧 Proposed (scoped to dotnet package flows, not dotnet tool)

• Mechanism: minPublishAgeHours per source in nuget.config (open spec)

• Reference: NuGet/Home#14657

A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:

• Registry: NuGet.org (pkg:nuget)

• Retraction: Yank (unlist): “nuget.org does not support permanent deletion of packages”, so an unlisted version leaves search and the gallery but “can still be downloaded and installed by using an exact version number” (policy). Malware is the carve-out, deleted outright, each removal landing in the public catalog as a PackageDelete leaf (catalog)

• Publish date: ✅ published on each registration catalogEntry, but overwritten with 1900-01-01T00:00:00+00:00 the moment a version is unlisted, and absent from the search resource (API)

With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.

Version probe

The version is probed by running:

$ dotnet --version
9.0.306

and extracted with:

r"^(?P<version>\d+\.\d+\.\d+\S*)"

Reference traces

Raw native outputs captured in the manager source: the reference mpm’s parsers were written against. If you know dotnet tool well and a transcript below looks wrong, or a newer release changed its output format, report it.

$ dotnet tool list --global
Package Id      Version      Commands
--------------------------------------
dotnet-ef       2.1.11       dotnet-ef

Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --dotnet installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.

Changelog

• 7.7.0.dev0 (unreleased)

  • Resolve the pkg:conda and pkg:nuget purl types, which both raised instead of routing: a type declared with no manager short-circuits the fallback that would otherwise match it against the manager IDs. pkg:conda now fans out to conda and pixi, and pkg:nuget reaches dotnet.

  • Add the .NET global tool manager with installed, search, install, upgrade and remove support, including version pinning. Both listings are column tables whose headers are localized, so the parsers key on the row shape and the CLI language is pinned through the environment.