Add tests for package@version and --version conflict validation in tool install/update

[Copilot]

The package@version syntax for dotnet tool install and dotnet tool update is already implemented via CommonArguments.ParsePackageIdentityWithVersionSeparator. The conflict validation (using both @version and --version) is also implemented in VersionRangeUtilities.GetVersionRange. However, there were no explicit tests for this validation.

Changes

• Added InstallToolWithBothAtVersionAndVersionOptionThrowsError test in InstallToolParserTests.cs
• Added UpdateToolWithBothAtVersionAndVersionOptionThrowsError test in UpdateToolParserTests.cs

Example

# This correctly errors with: "Cannot specify --version when the package argument already contains a version."
dotnet tool install -g [email protected] --version 2.0.0
dotnet tool update -g [email protected] --version 2.0.0

CLI Commands with Package IDs and --version options

Command	Supports package@version	Has conflict validation
dotnet package add	✅	✅
dotnet tool install	✅	✅
dotnet tool update	✅	✅
dotnet tool execute	✅	✅

Other commands like workload install/update use --sdk-version (not package versions), and package remove has no version option.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>dotnet tool install doesn't support package@version syntax</issue_title>
<issue_description>dotnet tool install dotnet-aspnet-codegenerator@9 today causes the tool installer to look for a package with the literal package Id dotnet-aspnet-codegenerator@9 instead of looking for the most recent stable 9.x version of the dotnet-aspnet-codegenerator package. This is inconsistent with the direction we've been taking other package+version-related commands.

We should ensure that this command (and dotnet tool update) support the package[@version] syntax, and that if that syntax is used the --version flag becomes a validation error.</issue_description>

<agent_instructions>implement this as described, and make sure to add tests for the new syntax and the --version validation.

after this is implemented, write a comment on the PR with a list of other CLI commands that accept package Ids and --version options, but not package@version syntax so we can see where the gaps are.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes dotnet tool install doesn't support package@version syntax #52706

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[baronfel]

/azp run dotnet-sdk-public-ci

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

Adds explicit regression tests ensuring dotnet tool install / dotnet tool update reject using both package@version and --version together (validating the existing conflict check surfaced via GracefulException).

Changes:

• Added a new test covering dotnet tool install -g package@version --version ... conflict behavior.
• Added a new test covering dotnet tool update -g package@version --version ... conflict behavior.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
test/dotnet.Tests/CommandTests/Tool/Install/InstallToolParserTests.cs	Adds a test asserting the @version + --version conflict throws the expected localized error.
test/dotnet.Tests/CommandTests/Tool/Update/UpdateToolParserTests.cs	Adds a parallel test for tool update validating the same conflict behavior.

[Copilot]

Cli.Commands... and Cli.CliStrings... won’t compile here because Cli isn’t in scope (there’s no using Microsoft.DotNet;/alias). Since you already import Microsoft.DotNet.Cli.Commands.Tool.Install, instantiate ToolInstallCommand directly, and reference the resource string as CliStrings.PackageIdentityArgumentVersionOptionConflict (add using Microsoft.DotNet.Cli; or fully-qualify Microsoft.DotNet.Cli.CliStrings).

[Copilot]

Cli.Commands... and Cli.CliStrings... won’t compile here because Cli isn’t in scope (there’s no using Microsoft.DotNet;/alias). Since you already import Microsoft.DotNet.Cli.Commands.Tool.Update, instantiate ToolUpdateCommand directly, and reference the resource string as CliStrings.PackageIdentityArgumentVersionOptionConflict (add using Microsoft.DotNet.Cli; or fully-qualify Microsoft.DotNet.Cli.CliStrings).