Migrate DotnetToolResource to use RequiredCommandValidator

[afscrome]

Description

• Migrated dotnet tool version validation to use RequiredCommandValidator
• Updated RequiredCommandValidator to include the callback in the cache key, so that resources for the same tool name, but different validation callbacks have the correct callback executed.

Fixes #14304

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
• Did you add public API?
  • No
• Does the change make any security assumptions or guarantees?
  • No
• Does the change require an update in our Aspire docs?
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15265

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15265"

[Copilot]

Pull request overview

This PR migrates DotnetToolResource’s .NET SDK version check to the shared RequiredCommandValidator flow and adjusts the validator’s caching behavior to account for different validation callbacks per command.

Changes:

• Add a WithRequiredCommand("dotnet", ...) validation to DotnetToolResource and remove the prior before-start SDK version check.
• Update RequiredCommandValidator caching to key by (command, validationCallback) instead of just command.
• Update/add tests for required-command caching behavior and for AddDotnetTool emitting the required-command annotation.

Reviewed changes

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

File	Description
tests/Aspire.Hosting.Tests/RequiredCommandAnnotationTests.cs	Adds coverage for caching behavior across identical vs different validation callbacks.
tests/Aspire.Hosting.DotnetTool.Tests/AddDotnetToolTests.cs	Removes direct SDK version validation unit tests; adds an assertion that AddDotnetTool includes a RequiredCommandAnnotation.
src/Aspire.Hosting/DotnetToolResourceExtensions.cs	Moves SDK version validation into a required-command validation callback and removes the prior before-start validation call.
src/Aspire.Hosting/ApplicationModel/RequiredCommandValidator.cs	Changes validation caching key to include the callback and introduces a cache-key type.

Comments suppressed due to low confidence (1)

src/Aspire.Hosting/ApplicationModel/RequiredCommandValidator.cs:106

• Including ValidationCallback in the cache key means missing-command failures (where resolved is null and the callback is never invoked) will no longer be coalesced across resources if they supply different callbacks for the same command. That can produce multiple identical warnings/notifications for a single missing executable. Consider splitting caching so command resolution/notification is keyed only by command, while callback execution results are cached separately (e.g., per-command state that tracks per-callback validation).

        // Get or create state for this command/callback combination.
        var cacheKey = new CommandValidationCacheKey(command, annotation.ValidationCallback);
        var state = _commandStates.GetOrAdd(cacheKey, _ => new CommandValidationState());

        await state.Gate.WaitAsync(cancellationToken).ConfigureAwait(false);
        try
        {
            // If validation already failed for this command, just log and return the cached failure
            if (state.ErrorMessage is not null)
            {
                _logger.LogWarning("Resource '{ResourceName}' may fail to start: {Message}", resource.Name, state.ErrorMessage);
                return RequiredCommandValidationResult.Failure(state.ErrorMessage);
            }

            // Check if already validated successfully
            if (state.ResolvedPath is not null)
            {
                _logger.LogDebug("Required command '{Command}' for resource '{ResourceName}' already validated, resolved to '{ResolvedPath}'.", command, resource.Name, state.ResolvedPath);
                return RequiredCommandValidationResult.Success();
            }

            // Perform validation
            var resolved = ResolveCommand(command);
            var isValid = true;
            string? validationMessage = null;

            if (resolved is not null && annotation.ValidationCallback is not null)
            {
                var context = new RequiredCommandValidationContext(resolved, _serviceProvider, cancellationToken);
                var result = await annotation.ValidationCallback(context).ConfigureAwait(false);
                isValid = result.IsValid;
                validationMessage = result.ValidationMessage;
            }

            if (resolved is null || !isValid)
            {
                var link = annotation.HelpLink;

                // Build the message for logging and exceptions (includes inline link if available)
                var message = (link, validationMessage) switch
                {
                    (null, not null) => validationMessage,
                    (not null, not null) => string.Format(CultureInfo.CurrentCulture, MessageStrings.RequiredCommandValidationFailedWithLink, command, validationMessage, link),
                    (not null, null) => string.Format(CultureInfo.CurrentCulture, MessageStrings.RequiredCommandNotFoundWithLink, command, link),
                    _ => string.Format(CultureInfo.CurrentCulture, MessageStrings.RequiredCommandNotFound, command)

[afscrome]

Should the command name have been case insensitive in the first place? Yes on windows commands are case insensitive, but that's not true for linux/mac.