feat(dotnet): support runtime-only installs

[fragon10]

Referencing discussion #8494

Summary

Adds support for installing .NET runtimes alongside or instead of SDKs, via an inline tool option (runtime). Uses the existing backend-name side bracket syntax options.

Usage

mise use dotnet[runtime=dotnet]@8.0.14
dotnet --list-runtimes

[tools]
dotnet = ["9", { version = "8.0.14", runtime = "dotnet" }]

Valid runtime values: dotnet, aspnetcore, windowsdesktop

Changes

• src/plugins/core/dotnet.rs:
  • Validate the runtime option value against known framework names.
  • Pass --runtime / -Runtime to the install script when the option is set.
  • Skip dotnet --version post-install check for runtime installs.
  • Route runtime uninstall paths (shared/<framework>/<version> instead of sdk/<version>).
• src/cli/uninstall.rs:
  • Reorder get_requested_tool_versions() so tvr.resolve() (which carries tool options) is pushed before filesystem matches. The unique_by dedup keeps the first entry, so the options-bearing ToolVersion now wins instead of being silently dropped.
• e2e/core/test_dotnet: Add tests for runtime-only install and invalid runtime option validation.
• docs/lang/dotnet.md: Document the runtime-only install feature, valid values, and usage notes.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to the .NET plugin, allowing users to install only the .NET runtime components without the full SDK. This is particularly useful for environments where only application execution is required, reducing overhead. Alongside this, a general improvement to CLI argument parsing was implemented, enabling more flexible inline option specification for any tool. These changes provide greater control and efficiency for managing .NET installations.

Highlights

• Runtime-only .NET Installs: Added support for installing .NET runtimes (e.g., dotnet, aspnetcore, windowsdesktop) instead of or alongside the full SDK, using an inline tool option like dotnet@8.0.14[runtime=dotnet].
• CLI Argument Parsing Enhancement: Fixed and enhanced the parsing of bracketed options (e.g., [key=val]) when they are specified on the version side of a tool argument (e.g., tool@version[key=val]). Previously, these options were only parsed from the backend-name side.
• Documentation and Testing: Included comprehensive documentation for the new runtime-only install feature and added end-to-end tests to cover successful runtime installations and validation of invalid runtime options.

Changelog

• docs/lang/dotnet.md
  • Added a new section detailing runtime-only installs, including usage examples and valid runtime values.
  • Included warnings about version numbers referring to runtimes, not SDKs, and the absence of SDK build tools in runtime-only installs.
  • Added a tip about channel syntax support for runtime installs.
• e2e/core/test_dotnet
  • Added a test case to verify successful runtime-only installation of .NET.
  • Added a test case to confirm that providing an invalid runtime option results in an appropriate validation error.
• src/cli/args/tool_arg.rs
  • Imported necessary functions for splitting and parsing bracketed options.
  • Modified the from_str implementation for ToolArg to extract and merge bracketed options from the version string (e.g., 8.0.14[runtime=dotnet]).
  • Added a new test case test_tool_arg_with_version_and_opts to validate the new parsing behavior for version-side options.
• src/plugins/core/dotnet.rs
  • Updated test_dotnet to skip the dotnet --version check for runtime-only installs, as they do not include the CLI.
  • Implemented logic in install_version to read and validate the runtime option, ensuring only allowed values are used.
  • Modified the install progress message to dynamically indicate whether an SDK or Runtime is being installed.
  • Updated install_cmd functions (for both Unix and Windows) to accept and pass the --runtime or -Runtime argument to the .NET install script when specified.
  • Enhanced uninstall_version to correctly handle the uninstallation of runtime-only components by targeting their specific shared directory paths.

Activity

• The pull request was created by fragon10 to address issue feat(dotnet): Support runtime-only .NET installs (--runtime flag) #8494, adding support for .NET runtime-only installs and fixing CLI argument parsing.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces support for runtime-only installations for .NET, a beneficial feature for users who only need to run applications without the full SDK. However, a significant Path Traversal vulnerability has been identified: the dotnet plugin uses user-controlled tool version strings to construct file paths for installation and uninstallation without sanitization, which could lead to arbitrary file or directory deletion. Strict validation or sanitization of version strings is highly recommended before filesystem operations. Additionally, consider refactoring the handling of runtime options in src/plugins/core/dotnet.rs to centralize validation and mapping logic for improved maintainability.

[gemini-code-assist]

The dotnet plugin uses the tool version string directly to construct file paths for installation and uninstallation without proper sanitization. Since the version string can be provided by a user via CLI arguments or a .mise.toml file, an attacker can provide a malicious version string containing path traversal characters (e.g., ..) to cause mise to create or delete arbitrary files or directories on the system.

For example, during uninstallation, if tv.version is .., the constructed runtime_dir or sdk_dir could resolve to the parent directory (e.g., the entire .dotnet-root directory), leading to unintended mass deletion of files when file::remove_all is called. Combined with more traversal components, this could target sensitive system files.

To remediate this, ensure the version string is sanitized to remove or reject path traversal characters before using it in path construction, or validate it against an expected version format.

[fragon10]

This mirrors the existing SDK uninstall pattern that was already here before this PR. The version string comes from Microsoft's API or from the user's own config — same trust level as running any shell command. Proper version sanitization should be a separate effort at a higher level in mise, not patched into individual backends.

This comment was generated by Claude Code.

[gemini-code-assist]

Similar to the runtime uninstallation logic, the SDK uninstallation logic uses tv.version unsafely to construct a path for deletion. This allows an attacker to trigger arbitrary file or directory deletion via path traversal in the version string.

[fragon10]

Pre-existing code, not introduced by this PR. Agreed that centralized version sanitization would be a good follow-up.

This comment was generated by Claude Code.

[greptile-apps]

Greptile Summary

This PR adds support for installing .NET runtimes (instead of, or alongside, the full SDK) via an inline runtime tool option (e.g. dotnet[runtime=dotnet]@8.0.14). The implementation validates the option against the three known framework names, threads the value through to the install script (--runtime / -Runtime), skips the dotnet --version post-install check for runtime-only installs, and routes the shared-mode uninstall to shared/<framework>/<version> rather than sdk/<version>. A companion fix in uninstall.rs reorders the TVR push so the options-bearing entry wins deduplication over the plain filesystem match.

Key changes:

• src/plugins/core/dotnet.rs — new runtime_framework_name helper; validation, install, and uninstall paths all branch on the runtime option.
• src/cli/uninstall.rs — TVR pushed before filesystem matches so unique_by keeps the options-bearing ToolVersion.
• e2e/core/test_dotnet — new tests for runtime install/uninstall round-trip and invalid option validation; uses 8.0.13 (not bundled by SDK 8.0.408) to prevent false-positives.
• docs/lang/dotnet.md — documents valid runtime values, mixed-install TOML example, and the channel-syntax limitation.

Issue found:

• The unique_by dedup key in uninstall.rs uses only (ba.short, version) without options. Now that SDK and runtime installs can legitimately coexist at the same version, simultaneously uninstalling both (e.g. mise uninstall \"dotnet[runtime=dotnet]@8.0.14\" \"dotnet@8.0.14\") silently drops one of the two requests.

Confidence Score: 3/5

Safe to merge for the common single-install use-case; the unique_by options-omission bug only surfaces when uninstalling SDK and runtime at the same version in one command.

The core feature (install, validate, uninstall, test coverage) is well-implemented and the previous review iterations addressed the main false-positive and cleanup concerns. One correctness gap remains: unique_by in uninstall.rs uses (ba.short, version) without options, so simultaneously uninstalling two coexisting install forms at the same version silently drops one. This is an edge case but is a logical regression introduced by this PR (prior to it, no two distinct installs could share a version under the same tool). All other paths look correct.

src/cli/uninstall.rs — the unique_by dedup key should include options to correctly handle the new SDK-and-runtime-at-the-same-version scenario.

Important Files Changed

Filename	Overview
src/plugins/core/dotnet.rs	Adds runtime-only install support by validating the runtime option, passing --runtime/-Runtime to the install script, skipping the dotnet --version post-install check, and routing uninstalls to shared/<framework>/<version> instead of sdk/<version>. Logic is correct; the silent Ok(()) on unknown runtime during uninstall was flagged in a prior thread and carries over unchanged.
src/cli/uninstall.rs	Reorders get_requested_tool_versions so the options-bearing TVR is pushed before filesystem matches, letting unique_by correctly keep the TVR. However, the dedup key (ba.short, version) omits options, which now matters because this PR makes it possible to have SDK and runtime installs at the same version — a simultaneous multi-uninstall of both forms silently drops one.
e2e/core/test_dotnet	Adds tests for runtime install (pre-check, install, verify via --list-runtimes, uninstall, verify cleaned up) and invalid runtime option validation. Uses 8.0.13 (not bundled by SDK 8.0.408) to avoid false-positives; stale-install cleanup guards are in place before the invalid-runtime assertion.
docs/lang/dotnet.md	Documents the new runtime option with valid values table, mixed SDK+runtime TOML example, and a tip warning that channel syntax is unsupported for runtime installs. Clear and accurate.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["mise install / mise x\ndotnet[runtime=X]@version"] --> B{runtime option\npresent?}
    B -- No --> C[Install .NET SDK\ndotnet-install.sh --version V]
    B -- Yes --> D{runtime_framework_name\nvalid?}
    D -- No --> E[Error: Invalid runtime option]
    D -- Yes --> F[Install .NET Runtime\ndotnet-install.sh --version V --runtime X]
    C --> G[Post-install:\ndotnet --version check]
    F --> H[Skip version check\nreturn Ok]
    G --> I{isolated mode?}
    H --> I
    I -- Yes --> J[install_path = installs/dotnet/version]
    I -- No --> K[install_path symlink → DOTNET_ROOT]

    L["mise uninstall\ndotnet[runtime=X]@version"] --> M[uninstall.rs:\npush TVR first then filesystem matches]
    M --> N[unique_by ba.short + version\nTVR wins over filesystem match]
    N --> O{uninstall_version_impl\nruntime option?}
    O -- Yes --> P[Remove\nDOTNET_ROOT/shared/Framework/version]
    O -- No --> Q[Remove\nDOTNET_ROOT/sdk/version]

Loading

Comments Outside Diff (1)

1. src/cli/uninstall.rs, line 51-54 (link)

   unique_by key silently drops one when SDK + runtime coexist at the same version

   unique_by uses only (ba.short, version) as the key — options like runtime=dotnet are not part of it. This PR introduces the first legitimate case where two distinct installs can share the same backend short name and version: dotnet@8.0.14 (SDK, no options) and dotnet[runtime=dotnet]@8.0.14 (runtime, runtime=dotnet option).

   If a user has both installed and runs:

   mise uninstall "dotnet[runtime=dotnet]@8.0.14" "dotnet@8.0.14"

   Both produce TVs with key ("dotnet", "8.0.14"). The unique_by keeps only the first entry (the runtime form) and silently discards the SDK uninstall request. The SDK at sdk/8.0.14/ is never cleaned up.

   The same problem applies within a single TA when a TVR with options is present: the filesystem match (created without options) deduplicates against the TVR correctly today, but if it represents a different kind of install (e.g., an SDK when the user specified a runtime TVR), it is discarded and the wrong uninstall_version_impl path runs.

   Consider including the serialised options in the dedup key so each distinct install form is treated independently:

   .unique_by(|(_, tv)| {
       (
           tv.request.ba().short.clone(),
           tv.version.clone(),
           tv.request.options().clone(),
       )
   })

_{Greploops — Automatically fix all review issues by running /greploops in Claude Code. It iterates: fix, push, re-review, repeat until 5/5 confidence.
Use the Greptile plugin for Claude Code to query reviews, search comments, and manage custom context directly from your terminal.}

_{Reviews (22): Last reviewed commit: "feat(dotnet): add support for runtime-on..." | Re-trigger Greptile}

[jdx]

The closing ::: on the warning block in docs/lang/dotnet.md is indented by 2 spaces — this will leave the container unclosed in VitePress. Can you move it to column 0?

- Runtime-only installs do **not** include the SDK build tools...
-  :::
+- Runtime-only installs do **not** include the SDK build tools...
+:::

This comment was generated by Claude Code.

[fragon10]

The closing ::: has been relocated to column 0 on the next row, due to lint-fix re-formatting.

Perhaps bullet-points inside admonition containers prevent the opening and closing ::: to be directly prior or after the text-content.
I hope this renders well, if not, I could re-phrase the text-content within.

[fragon10]

Comments Outside Diff (1)

1. `src/cli/uninstall.rs`, line 51-54 ([link](https://github.com/jdx/mise/blob/4a5d925dfb025d80a1f0c337b39507e6be2c6015/src/cli/uninstall.rs#L51-L54))
   **`unique_by` silently drops one entry when SDK and runtime share the same version string**
   The dedup key is `(ba.short, tv.version)` — it intentionally excludes options so that a tvr-resolved entry (with options) beats its filesystem duplicate (same version, no options) within a single `ta` iteration. That part works correctly after the reorder.
   However, if a user specifies _both_ `dotnet@8.0.13` (SDK) and `dotnet[runtime=dotnet]@8.0.13` (runtime) in a single uninstall command, the outer `unique_by` sees two entries with key `("dotnet", "8.0.13")` and silently drops whichever comes second — so only the first-specified variant is uninstalled.
   In practice this is unlikely because SDK and runtime versions rarely share the same string (e.g., SDK `8.0.408` ships with Runtime `8.0.14`). But now that mis-matching through options is part of the public interface, it is a correctness gap worth tracking.
   To fully fix it, the dedup key should include options:
   ```rust
   .unique_by(|(_, tv)| {
       (
           tv.request.ba().short.clone(),
           tv.version.clone(),
           tv.request.options().clone(),
       )
   })
   ```

   This preserves the existing dedup behaviour (eliminates the filesystem-match duplicate within a single `ta`, since both have the same options) while also allowing SDK and runtime of the same version to both be uninstalled in one command.

Regarding Greptile's unique_by dedup key finding (uninstall.rs:51-54):

Raises a valid point, however, it's a pre-existing issue, not introduced by this PR. Also the likelihood of this collision is very low, especially for dotnet.
With that said, the fix is a one-liner since ToolVersionOptions already derives Hash and Eq.

Would it be preferable to include this fix here or as a separate (follow-up) PR?