Fix userlocal

[Forgind]

Fixes #41420 and #41726

This attempts to find everywhere that we currently assume not-userlocal (where it's supported) and changes it to respect userlocal if specified.

As far as testing, I tried to do dotnet workload update with an SDK without this update, and it broke. I then tried it with these changes, and it succeeded.

I'm not very knowledgeable about what scenarios I should target. I'll keep testing things I can think of, but do either of you have a suggestion on where to focus my testing energy @baronfel @tmds?

[baronfel]

It looks like the two changes are in the main dotnet.dll and the resolver dll, right? So it could be a viable test to

• get an Ubuntu or Red Hat WSL instance
• install an 8.x sdk from distro sources
• drop newly-built patched dlls onto that install
• test workload install/update?

[baronfel]

Conceptually, it worries me how many distinct places you had to touch to fix this. It feels like we need some abstraction/mediator that we can ask for what this path should be to ensure that no code has the wrong idea.

[Forgind]

Conceptually, it worries me how many distinct places you had to touch to fix this. It feels like we need some abstraction/mediator that we can ask for what this path should be to ensure that no code has the wrong idea.

I think this is an excellent point. What makes this hard is that all the load-bearing changes are pretty clearly in one of three buckets: related to the install state, related to workload sets, or related to garbage collection, and for the first two cases, at least, even if something perfect existed, I wouldn't have known to reference it. There are a few rare cases in which we really do want the not-userlocal dotnet path regardless, notably as a fallback path in the resolver, so we can't just fully replace dotnetPath with dotnetOrUserLocalPath...

[kasperk81]

It feels like we need some abstraction/mediator that we can ask for what this path should be to ensure that no code has the wrong idea.

simplification idea: remove dotnetPath argument from WorkloadInfoHelper and directly call CliFolderPathCalculatorCore.GetDotnetHomePath() for !IsUserLocal when initializing WorkloadInfoHelper.DotnetPath. it is still going through a wrapper but less fragmented in comparison.

[marcpopMSFT]

Hold for the workload set PR but this looks good otherwise