Add warnings for newer tool versions during dotnet tool restore

[Copilot]

Summary

This PR enhances dotnet tool restore to show warnings when newer versions of tools are available in the configured package sources. This helps users stay informed about available updates and can prevent issues where outdated tools cause compatibility problems with newer SDKs.

Changes

Core Functionality

• Enhanced ToolRestoreResult: Added Warning property to carry version update notifications
• Version Checking Logic: Added CheckForNewerVersion() method in ToolPackageRestorer that:
  • Uses wildcard version ranges (*) to query the latest available version from package sources
  • Compares semantic versions between manifest and latest available
  • Applies smart logic for prerelease vs stable versions
  • Gracefully handles network failures without breaking restore functionality
• Display Enhancement: Modified PrintConclusionAndReturn() to display warnings in yellow text after successful restore messages

User Experience

• Localized Messages: Added RestoreNewVersionAvailable resource string with clear, actionable messaging
• Non-Intrusive: Warnings only appear during dotnet tool restore, never during tool execution
• Resilient: Network issues or package source problems don't cause restore failures

Example Output

Before:

Tool 'dotnet-ef' (version '6.0.0') was restored. Available commands: dotnet-ef

Restore was successful.

After:

Tool 'dotnet-ef' (version '6.0.0') was restored. Available commands: dotnet-ef

A newer version of tool 'dotnet-ef' is available (version '9.0.9'). Consider updating your manifest file.

Restore was successful.

Testing

• Added comprehensive unit test coverage for the warning functionality
• Verified with real-world packages (dotnet-ef, powershell) showing proper version detection
• Confirmed warnings only appear during restore operations, not tool execution
• Validated all existing tests pass with no regressions
• Tested edge cases including latest versions, multiple tools, and network failures

Behavior Notes

• Scope: Only applies to local tools defined in .config/dotnet-tools.json files
• Version Logic: Shows warnings for newer stable versions, or any newer version if current is prerelease
• Performance: Adds minimal overhead during restore by reusing existing package query infrastructure
• Backward Compatibility: No breaking changes to existing functionality

This addresses the scenario described in the issue where CI systems fail due to outdated tools, but users aren't aware that newer compatible versions are available.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>dotnet tool restore should provide warnings if new versions of tool is available</issue_title>
<issue_description>### Is your feature request related to a problem? Please describe.
Our CI stopped working as tool needed an old version of SDK (6), which was removed from VM, but tool was on an old version in our .config/dotnet-tools.json... however a new version of the tool was available which worked as-is, but we didn't know at first that this was an option.

Describe the solution you'd like

It'd be great when running dotnet tool restore that if new versions of tools are available, that a warning is outputted to the console which specifies the latest version number.

Even better if there's a way to auto-update the config to use the latest version of all tools in it locally.

Additional context

Add any other context or screenshots about the feature request here.

microsoft/NativeAOTDependencyHelper#16

Related to #38172</issue_description>

<agent_instructions>This should only apply to local tools that are defined in a json file. It should not affect commands outside of restore. For example, if a customer does a tool run, it should use the version in the local tools .json without warning.</agent_instructions>

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

Fixes #50991

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[marcpopMSFT]

@baronfel I tested and this new code only runs if the current version of the tool is not found in the cache. That seems like an ok compromise to me as otherwise, we're hitting the network when theoretically we don't need to. However, it does mean that if you have the tool installed locally, you'll never get the notice.

[marcpopMSFT]

Tool 'dotnetsay' (version '2.1.1') was restored. Available commands: dotnetsay

A newer version of tool 'dotnetsay' is available (version '2.1.7'). Consider updating your manifest file.

[baronfel]

That's an interesting compromise for sure. I could see a dotnet tool check command in the future for more comprehensive checking.

[marcpopMSFT]

or a flag to dotnet tool restore which asks for the check. Either way, this change is reasonable and working as is so published for review.

[Copilot]

Pull Request Overview

This PR adds functionality to display warnings when newer versions of tools are available during dotnet tool restore operations. This helps users stay informed about tool updates and prevent compatibility issues with newer SDKs.

Key Changes:

• Enhanced restore functionality to check for newer tool versions and display warnings
• Added localized warning messages for the new version notification feature
• Implemented comprehensive test coverage for the warning functionality

Reviewed Changes

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

Show a summary per file

File	Description
ToolPackageRestorer.cs	Added version checking logic and warning generation functionality
ToolRestoreCommand.cs	Enhanced result structure and display logic to show version warnings
CliCommandStrings.resx	Added the new localized message string for version warnings
Multiple .xlf files	Added localization entries for the new warning message
ToolRestoreCommandTests.cs	Added comprehensive test coverage for the warning functionality

[Copilot]

The .xlf files should be updated using the /t:UpdateXlf MSBuild target rather than manually adding entries. These manually added entries have the incorrect state 'new' instead of 'needs-review-translation'.

[marcpopMSFT]

@nagilson do you know if your instruction update PR will help as all of these reviews seem wrong to me? https://github.com/dotnet/sdk/pull/51158/files

New seems fine and new is listed in the copilot instructions as fine.

[nagilson]

My intention wasn't to give copilot instructions but to make a github actions workflow where we could type /updatexlf and it would suggest changes based on the results of running that command. And same for /fixcompletions to fix those tests. #51158

I like the idea of updating the copilot instructions as well though. But the PR AI isn't very good from my perspective, so it may not help. It's worth trying!

[KalleOlaviNiemitalo]

This PR enhances dotnet tool restore to show warnings when newer versions of tools are available in the configured package sources.

I saw this and immediately worried about such a warning getting triggered in an automated build, being parsed by Jenkins and causing the build to be considered UNSTABLE.

It looks like the output is not actually formatted anything like "warning SDK0000: tool is not the latest available version" though, so it won't be parsed as a warning. Please call it a note, then.

[marcpopMSFT]

@KalleOlaviNiemitalo yeah, this in the bucket of CLI messages so shouldn't impact exit codes or builds. It can impact if someone is processing the output.