Remove ConfigureAwait from the Cli

[eerhardt]

Description

Since the CLI is a console application, requiring ConfigureAwait everywhere isn't necessary.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
• Are you including unit tests for the changes and scenario tests if relevant?
  • No
• 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

[Copilot]

Pull Request Overview

This PR removes all instances of .ConfigureAwait from asynchronous calls in the CLI, aligning with the CLI’s console-based context where context capturing is unnecessary. The changes improve code readability and simplify async code in several areas.

• Removal of .ConfigureAwait calls for asynchronous operations.
• Updates to command configuration and process execution methods.
• Consistent changes across Program.cs, DotNetCliRunner.cs, NuGetPackageCache.cs, and AppHostBackchannel.cs.

Reviewed Changes

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

File	Description
Aspire.Cli/Program.cs	Removed ConfigureAwait calls in Run, Build, New, and Add command configurations.
Aspire.Cli/DotNetCliRunner.cs	Removed ConfigureAwait from process execution and backchannel-related asynchronous calls.
Aspire.Cli/NuGetPackageCache.cs	Removed ConfigureAwait from package search and retrieval methods.
Aspire.Cli/Backchannel/AppHostBackchannel.cs	Removed ConfigureAwait from backchannel connectivity and RPC invocation methods.

Files not reviewed (1)

• .editorconfig: Language not supported

[joperezr]

Probably a dumb question, but isn't also there performance reasons to use ConfigureAwait(false) as you would then not need to capture the synchronization context?

[joperezr]

I understand that this is mostly useful on libraries, but at least the rule of thumb that I used to follow is to always use ConfigureAwait unless you explicitly know that you want to use the same context.

[eerhardt]

but isn't also there performance reasons to use ConfigureAwait(false) as you would then not need to capture the synchronization context?

Console applications use the default SynchronizationContext (unless you set one explicitly, which we don't).

https://devblogs.microsoft.com/dotnet/configureawait-faq/#when-should-i-use-configureawait(false)

Even with these special cases, the general guidance stands and is a very good starting point: use ConfigureAwait(false) if you’re writing general-purpose library / app-model-agnostic code, and otherwise don’t.

[joperezr]

Got it, thanks for sharing the link. This LGTM.