Encapsulate SDK installation decision in CheckAsync

[Copilot]

Refactors SDK installation logic to move the decision of whether to install into CheckAsync itself, removing user prompts and making installation automatic based on feature flags.

Changes

New CheckInstallResult class - Replaces tuple return with structured result:

public sealed class CheckInstallResult
{
    public bool Success { get; init; }
    public string? HighestVersion { get; init; }
    public string MinimumRequiredVersion { get; init; }
    public bool ForceInstall { get; init; }
    public bool ShouldInstall { get; init; }  // Determined automatically
}

DotNetSdkInstaller.CheckAsync - Now determines installation automatically:

• Returns CheckInstallResult instead of tuple
• Sets ShouldInstall based on feature flags and environment capabilities
• Checks for private SDK installations before checking system PATH

SdkInstallHelper.EnsureSdkInstalledAsync - Simplified to remove prompting:

• No longer takes IFeatures or ICliHostEnvironment parameters
• Installs automatically when result.ShouldInstall is true
• Removed user confirmation prompt logic

Command updates - All commands now use simplified signature:

// Before
await SdkInstallHelper.EnsureSdkInstalledAsync(
    sdkInstaller, InteractionService, features, hostEnvironment, cancellationToken)

// After
await SdkInstallHelper.EnsureSdkInstalledAsync(
    sdkInstaller, InteractionService, cancellationToken)

Test updates - Fixed compilation errors from tuple → object change:

• Updated test factories to create CheckInstallResult objects
• Changed assertions from tuple deconstruction to property access
• Fixed reflection-based tests for simplified MeetsMinimumRequirement signature

Original prompt

Create a coding agent PR but don't make any changes beyond my modifications here. Once we've got a build running I'll suggest additional changes.

[Chronological Review: The conversation began with the user requesting changes to the `SdkInstallHelper` and `DotNetSdkInstaller.CheckAsync` methods to encapsulate the SDK installation logic within `CheckAsync`. The user later clarified that the installation should be automatic without prompting the user. Finally, the user requested the creation of a pull request (PR) for the modifications made, indicating that no further changes should be made until a build is running.]

[Intent Mapping:

1. "Change the logic in SdkInstallHelper and DotNetSdkInstaller.CheckAsync so that the determination on whether the SDK should be installed is made within CheckAsync itself."
2. "Change the CheckAsync method to return an object which is CheckInstallResult which has the values from the tuple along with a ShouldInstall value."
3. "I forgot to mention we no longer want to prompt to install. The determination on whether we should install will be automatic based on the checks inside CheckAsync."
4. "Create a coding agent PR but don't make any changes beyond my modifications here. Once we've got a build running I'll suggest additional changes."]

[Technical Inventory:

• SdkInstallHelper.cs: The file being modified to change SDK installation logic.
• CheckAsync: Method within DotNetSdkInstaller that needs to be updated to return a CheckInstallResult object.
• CheckInstallResult: New object structure to include installation determination logic.]

[Code Archaeology:

• SdkInstallHelper.cs: The user is focused on modifying this file to implement the new logic for SDK installation.
• CheckAsync: Needs to be updated to include a ShouldInstall value in its return type.]

[Progress Assessment:

• Completed Tasks: User has specified the changes needed in SdkInstallHelper and CheckAsync.
• Partially Complete Work: The actual code modifications have not yet been executed, but the user has provided clear instructions for the changes.]

[Context Validation: All necessary context for continuing work on the SdkInstallHelper and CheckAsync methods is captured, including the requirement for automatic installation without user prompts.]

[Recent Commands Analysis:

• Last Agent Commands: The user requested to create a PR for the modifications made to SdkInstallHelper.cs.
• Tool Results Summary: No specific tool results were returned as the user was focused on outlining the changes and requesting a PR.
• Pre-Summary State: The agent was preparing to create a PR based on the user's modifications to the SDK installation logic.
• Operation Context: The commands executed were directly related to the user's goal of modifying the SDK installation process and preparing for further changes after a successful build.]

1. Conversation Overview: - Primary Objectives: - "Change the logic in SdkInstallHelper and DotNetSdkInstaller.CheckAsync so that the determination on whether the SDK should be installed is made within CheckAsync itself." - "Change the CheckAsync method to return an object which is CheckInstallResult which has the values from the tuple along with a ShouldInstall value." - "I forgot to mention we no longer want to prompt to install. The determination on whether we should install will be automatic based on the checks inside CheckAsync." - "Create a coding agent PR but don't make any changes beyond my modifications here. Once we've got a build running I'll suggest additional changes." - Session Context: The user is modifying SDK installation logic in the `SdkInstallHelper` and `DotNetSdkInstaller` classes, focusing on automatic installation without user prompts. - User Intent Evolution: The user initially requested specific changes to the installation logic and later clarified the need for automatic behavior without prompts.

2. Technical Foundation:

• SdkInstallHelper.cs: The file being modified to implement new logic for SDK installation.
• CheckAsync: Method that needs to be updated to return a CheckInstallResult object.
• CheckInstallResult: New object structure to include installation determination logic.

3. Codebase Status:

• SdkInstallHelper.cs:
  • Purpose: Contains logic for SDK installation.
  • Current State: Awaiting modifications as per user requests.
  • Key Code Segments: Focus on CheckAsync method changes.
  • Dependencies: Related to the installation process of the SDK.

4. Problem Resolution:

• Issues Encountered: Need for a change in logic to automate SDK installation.
• Solutions Implemented: User has provided clear instructions for the required changes.
• Debugging Context: No ongoing troubleshooting efforts mentioned.
• Lessons Learned: Importance of clear communication regarding user prompts and installation logic.

5. Progress Tracking:

• Completed Tasks: User has specified the changes neede...

Created from VS Code via the GitHub Pull Request extension.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[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 -- 12367

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull Request Overview

This PR refactors the SDK installation logic to encapsulate the installation decision within CheckAsync, making SDK installation automatic based on feature flags rather than prompting users. The changes replace a tuple-based return type with a structured CheckInstallResult class and simplify the installation flow by removing user confirmation prompts.

Key changes:

• Introduced CheckInstallResult class to provide structured return data from SDK checks
• Moved installation decision logic into CheckAsync via new DetermineShouldInstall method
• Removed user prompting from SdkInstallHelper.EnsureSdkInstalledAsync and simplified its signature

Reviewed Changes

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

Show a summary per file

File	Description
src/Aspire.Cli/DotNet/CheckInstallResult.cs	New class defining structured result for SDK check operations
src/Aspire.Cli/DotNet/IDotNetSdkInstaller.cs	Updated interface to return CheckInstallResult instead of tuple
src/Aspire.Cli/DotNet/DotNetSdkInstaller.cs	Refactored to return CheckInstallResult, added DetermineShouldInstall method, and added ICliHostEnvironment parameter
src/Aspire.Cli/Utils/SdkInstallHelper.cs	Simplified to remove IFeatures and ICliHostEnvironment parameters and user confirmation prompt logic
src/Aspire.Cli/Commands/*.cs	Updated all command classes to use simplified EnsureSdkInstalledAsync signature
src/Aspire.Cli/NuGet/NuGetPackagePrefetcher.cs	Updated to use CheckInstallResult properties instead of tuple deconstruction
tests/Aspire.Cli.Tests/DotNetSdkInstallerTests.cs	Updated tests to create CheckInstallResult objects and use property access instead of tuple deconstruction
tests/Aspire.Cli.Tests/Commands/SdkInstallerTests.cs	Updated test factories to create CheckInstallResult objects
tests/Aspire.Cli.Tests/TestServices/TestDotNetSdkInstaller.cs	Updated mock to return CheckInstallResult instead of tuple

[Copilot]

The XML documentation for DetermineShouldInstall should include a <remarks> section explaining the conditions under which installation occurs. Consider adding: <remarks>Installation occurs when: (1) The SDK check failed or force install is enabled, (2) The DotNetSdkInstallationEnabled feature is enabled, and (3) The environment supports interactive input or force install is enabled.</remarks>

[Copilot]

The summary documentation for MeetsMinimumRequirement is incomplete and should be updated to reflect the current behavior. It should state: 'Checks if an installed SDK version meets the minimum requirement using strict semantic version comparison.'