-
Couldn't load subscription status.
- Fork 713
Description
Is there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
Looking at an eval profile of an Aspire AppHost project, the apphost took ~1.5s to evaluate. This is pretty bad in general, but a full 215ms of this time was performing SDK Resolution for the Workloads SDK resolver.
Describe the solution you'd like
Since Aspire is no longer a workload, and since the Aspire AppHost doesn't need workloads itself, it would be great if the Aspire SDK specifically in its Sdk.props set MSBuildEnableWorkloadResolver to false. This needs to happen in the Aspire SDK's Sdk.props file due to ordering, and it'd also only apply if the Aspire SDK was loaded before the base .NET SDK.
Additional context
I think most of this time is the first-load XML cache cost (repeated loads of the same XML likely wouldn't show up) but we cna at least not make the Aspire AppHost to cause of this.
No response