Inject DOTNET_CLI_USE_MSBUILD_SERVER env var for apphost builds and runs, using configuration for value

[Copilot]

Fixes #9945

This PR implements the enhancement to the Aspire CLI to always set the DOTNET_CLI_USE_MSBUILD_SERVER environment variable for all dotnet build and dotnet run (when noBuild == false) calls for apphost projects.

Changes Made

Core Implementation

• Modified DotNetCliRunner to accept IConfiguration dependency via constructor
• Added GetMsBuildServerValue() helper method that reads from configuration["DOTNET_CLI_USE_MSBUILD_SERVER"] with default value of "true"
• Updated BuildAsync() to always inject the environment variable before calling ExecuteAsync
• Updated RunAsync() to inject the environment variable only when noBuild == false, preserving existing environment variables
• Updated service registration in Program.cs to provide IConfiguration to DotNetCliRunner

Test Coverage

Added comprehensive tests to verify:

• Environment variable defaults to "true" when not set in configuration
• Environment variable can be overridden via configuration for testing or explicit opt-out
• Environment variable is always present for builds
• Environment variable is only present for runs when noBuild == false
• Existing environment variables are preserved when injecting the new variable

Technical Implementation Details

✅ Always inject the DOTNET_CLI_USE_MSBUILD_SERVER environment variable into the environment dictionary passed to the build/run process for apphost builds
✅ The value is sourced from configuration["DOTNET_CLI_USE_MSBUILD_SERVER"] with fallback to "true"
✅ Never check for or rely on any preexisting value in the env dictionary; always explicitly set the variable
✅ In BuildAsync(): Always inject the variable before calling ExecuteAsync
✅ In RunAsync(): Inject the variable only if noBuild == false, before calling ExecuteAsync
✅ DotNetCliRunner has access to IConfiguration instance via dependency injection

Testing

• All existing CLI tests continue to pass (70/70)
• Added 5 new focused tests covering the environment variable injection behavior
• Tests verify default values, configuration overrides, and conditional injection based on noBuild parameter

The implementation is minimal and surgical, preserving all existing functionality while adding the required environment variable injection capability.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[davidfowl]

@copilot try again

[davidfowl]

@copilot try again

[Copilot]

Copilot wasn't able to review any files in this pull request.

[mitchdenny]

@copilot can you get started on this PR.

[mitchdenny]

Tested this out in a devcontainer and it looks like the server is starting (based on what the docs say). Unit tests seem to cover the edge cases.

[davidfowl]

@baronfel where should we be seeing performance improvements?

[baronfel]

The main benefit today is saving the ~1-1.5s MSBuild entry node startup time. Thats not always needed today but when we AOT the dotnet CLI that'll become critical because we can't host the MSBuild central node in the dotnet CLI process anymore. And on top of that we'll be hosting the MSBuild eval cache off of that server node as well, so you'll be well positioned to just immediately get that when it lands post-10.

[mitchdenny]

We may as well merge this then ... its ready to go.