`dotnet workload restore` installs "aspire" though it isn't needed or wanted

[AArnott]

Aspire seems to be pushed too hard on folks who don't need or want it.

Repro steps

git clone https://github.com/AArnott/Library.Template
cd Library.Template
dotnet workload restore

Expected

No workloads installed, because none are required for this repo.

Actual

Aspire is (allegedly) installed:

Installing workloads:

Successfully installed workload(s) aspire.

It gets worse

In fact the following repro, on the same machine, tries to elevate to install Aspire-related stuff:

dotnet new classlib -o aspire
cd aspire
dotnet workload restore

Produces this output:

Installing workloads:

Writing install records for Visual Studio workloads: 'aspire' Workload installation failed: An error occurred trying to start process '"C:\Program Files\dotnet\dotnet.exe"' with working directory 'C:\temp\aspire'. The operation was canceled by the user.

It says it was canceled because a UAC prompt appeared, which I rejected. Why would aspire be considered required here?

[marcpopMSFT]

I think what's happening is that we don't actually check if your project uses any workloads before starting the restore. That means we update manifests and any workloads from VS even if we return zero workloads. We basically assumed that you wouldn't run workload restore if you weren't actually using workloads but that's probably a bad assumption since some customers may run that almost reflexibly.

[AArnott]

Well, maybe that's part of it, but I do have repos that use workloads (android and ios) so I'm using them alright, and they too restore aspire though it does not apply. I saw this just yesterday while using the 8.0.400 SDK.

[marcpopMSFT]

Triage: We try to update manifests whenever running workloads commands and when we detect there are workloads installed from VS, we try to update from VS. Running workload restore should be safe to run. I think the question is will it be common for customers to run workload restore on projects that don't need it and have workloads installed from VS where we try to keep the CLI in sync with VS.

For now, we'll keep this on the backlog and see if we get more feedback from customers hitting this specific scenarios.

[dsplaisted]

Successfully installed workload(s) aspire.

This is likely because Aspire was installed as part of Visual Studio.

When you do a workload installation command (which includes workload restore), we sync the records of workloads installed by the SDK with the ones that VS installed. This helps prevent issues when updating workloads from the command line.