registry: alias dotnet-core to dotnet

[risu729]

Summary

dotnet-core is a legacy shorthand for the .NET SDK. This PR aliases it to the existing dotnet registry tool instead of adding another plugin backend to registry/dotnet-core.toml.

Changes:

• add dotnet-core as an alias of dotnet
• remove the separate registry/dotnet-core.toml entry
• canonicalize dotnet-core to dotnet in backend parsing, matching the existing nodejs -> node and golang -> go compatibility aliases

Why this is an alias, not a runtime option

The old mise-plugins/mise-dotnet-core asdf plugin installs SDKs, not runtime-only packages:

• bin/list-all reads Microsoft's release metadata and returns each channel's latest-sdk
• bin/install downloads Microsoft's dotnet-install.sh and runs it with --version <version> and no --runtime

So core:dotnet already covers the behavior that dotnet-core users expect. I did not use core:dotnet[runtime=dotnet] because that option means the .NET runtime-only package (Microsoft.NETCore.App), while core:dotnet latest/prefix resolution currently resolves SDK versions. Mixing SDK version resolution with --runtime dotnet would not preserve the old plugin behavior and can ask the installer for runtime versions that do not exist.

Why canonicalization is included

A separate registry/dotnet-core.toml pointing directly at core:dotnet would make two registry shorthands resolve to the same core plugin. Core plugins are singleton backend implementations keyed by their canonical tool name, so leaving dotnet-core as its own backend identity risks split behavior where a request uses dotnet-core paths/options while the core plugin reports metadata under dotnet.

Canonicalizing dotnet-core to dotnet avoids that edge case. It keeps the compatibility spelling available, but internally uses the same tool identity, install path, registry defaults, and metadata path as dotnet.

Compatibility impact

This is intentionally a consolidation, not a second core:dotnet registry identity:

• mise install dotnet-core and mise install dotnet now both use the canonical $MISE_INSTALLS_DIR/dotnet install directory.
• Existing installs that only exist under the legacy $MISE_INSTALLS_DIR/dotnet-core directory will not be discovered through the dotnet-core shorthand after this change; users will need to reinstall with mise install dotnet-core/mise install dotnet or migrate that install manually.
• The old default backend for dotnet-core was asdf:mise-plugins/mise-dotnet-core; the new default is the built-in core:dotnet SDK backend.
• This keeps one .NET SDK identity in mise rather than supporting two install roots for the same SDK tool.

Popularity

• GitHub dotnet/runtime: 17,883 stars, 5,442 forks, latest release v11.0.0-preview.4.26230.115 published 2026-05-12, pushed 2026-05-14.
• GitHub dotnet/sdk: 3,125 stars, 1,242 forks, latest release v8.0.421 published 2026-05-12, pushed 2026-05-14.
• This is an existing registry shorthand; this PR does not add a new tool, it aliases the legacy name to the existing dotnet SDK tool.

Local verification

mise run format
git diff --check
cargo test test_unalias_backend
cargo test cli::args::backend_arg::tests::test_backend_arg -- --exact
cargo test cli::args::backend_arg::tests::test_backend_arg_pathname -- --exact
target/debug/mise registry dotnet-core
target/debug/mise registry dotnet
target/debug/mise registry --json dotnet-core
target/debug/mise registry --hide-aliased | rg '^dotnet\\s'
target/debug/mise registry | rg '^dotnet(-core)?\\s'
MISE_USE_VERSIONS_HOST=false target/debug/mise latest dotnet-core # 10.0.300
MISE_USE_VERSIONS_HOST=false target/debug/mise latest dotnet      # 10.0.300
mise run test:e2e e2e/cli/test_registry

Compatibility checks

• mise registry dotnet-core still resolves and reports the same backends as dotnet.
• mise registry --hide-aliased hides dotnet-core, so the canonical registry listing remains dotnet.
• Existing dotnet-core CLI/config input is normalized to dotnet, avoiding a second core-plugin install identity.
• The old asdf plugin installed SDK versions, so core:dotnet is the correct replacement; core:dotnet[runtime=dotnet] would be a runtime-only install and is not equivalent.

This PR was prepared with an AI coding assistant.

[greptile-apps]

Greptile Summary

This PR aliases the legacy dotnet-core shorthand to the existing dotnet registry tool, removing the separate registry/dotnet-core.toml entry and adding canonicalization in unalias_backend so that dotnet-core input is normalized to dotnet at the BackendArg level — matching the existing nodejs → node and golang → go patterns.

• registry/dotnet.toml: adds aliases = ["dotnet-core"]; the build system inserts a duplicate registry entry for "dotnet-core" pointing to the same RegistryTool, and --hide-aliased correctly hides it because "dotnet-core" != rt.short ("dotnet").
• src/backend/mod.rs: adds "dotnet-core" => "dotnet" to unalias_backend, ensuring BackendArg::from("dotnet-core") sets short = "dotnet" and installs_path = $MISE_INSTALLS_DIR/dotnet.
• Breaking change (explicitly documented): existing installs under $MISE_INSTALLS_DIR/dotnet-core/ (from the old asdf:mise-plugins/mise-dotnet-core plugin) will no longer be discovered; users must reinstall or migrate the directory manually.

Confidence Score: 5/5

Safe to merge — the aliasing mechanics are correct, consistent with existing patterns, and the intentional breaking change for legacy install paths is explicitly documented in the PR description.

All four changed files implement exactly what the PR describes. The registry alias is emitted correctly at build time, unalias_backend canonicalises the name before installs_path is computed, and --hide-aliased suppresses "dotnet-core" as expected. No logic errors or unintended side-effects were found. The install-path migration impact is real but intentional and fully documented.

No files require special attention.

Important Files Changed

Filename	Overview
registry/dotnet.toml	Adds aliases = ["dotnet-core"] so the build system generates a duplicate registry entry for "dotnet-core" pointing at the same RegistryTool (short: "dotnet"). Together with unalias_backend, this makes "dotnet-core" fully resolve to the canonical core:dotnet identity.
registry/dotnet-core.toml	Deleted; the separate asdf:mise-plugins/mise-dotnet-core backend entry is replaced by the alias in dotnet.toml.
src/backend/mod.rs	Adds "dotnet-core" => "dotnet" to unalias_backend, consistent with the existing nodejs -> node and golang -> go patterns. Test coverage added.
src/cli/args/backend_arg.rs	Adds two tests: one verifying dotnet-core resolves to full="core:dotnet" / tool_name="dotnet" / BackendType::Core, and one verifying the install path resolves to installs/dotnet (not installs/dotnet-core).

_{Reviews (5): Last reviewed commit: "chore(schema): restore prettier formatti..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request updates the registry/dotnet-core.toml file by adding the vfox:mise-plugins/vfox-dotnet backend to the list of backends for .Net Core. There are no review comments, and I have no feedback to provide.

[risu729]

Greptile raised a valid compatibility concern: aliasing dotnet-core to dotnet changes the canonical install root from /dotnet-core to /dotnet, so existing legacy installs under the old directory will not be reused automatically.

I updated the PR body to document that impact explicitly. I left the implementation as a canonical alias because preserving a separate dotnet-core install identity would recreate the two-core-plugin-identity issue this change is meant to avoid.

This comment was generated by an AI coding assistant.