Setting DOTNET_HOST_PATH is not a good move :) about proj-info

[baronfel]

I think DOTNET_HOST_PATH was required for some msbuild targets/props/shenanigans, so we should require it in some way, but I agree with you that the last-chance fallback of the app name isn't suitable for cases where the caller is in an AppHost and not the dotnet host. I think we can remove that last-chance and raise an exception in the init function if that's the case. That will require callers to set at least one of the valid detection variables, though, which ideally would be represented as an input to the function somehow...

[baronfel]

One hurdle here is that the .NET SDK doesn't forward any of the environment variables we look for on to local or global tools, like it does for other commands. It might be good to advocate for that feature, because as it stands, tools have no consistent way to detect the dotnet installation that's running them.

[baronfel]

Talking with some of the SDK team, the DOTNET_ROOT variable is only set if the install location isn't one of the well-known ones. So we should do probing if there's no DOTNET_ROOT.

[baronfel]

The final algorithm should look something like:

• DOTNET_HOST_PATH
• DOTNET_ROOT/DOTNET_ROOT(x86)
• probe PATH
• probe default install locations per-OS
• fail hard if none found

[baronfel]

@dsyme this was released in 0.55.1

[baronfel]

@dsyme ok, 0.55.2 has a more sane strategy that doesn't touch DOTNET_HOST_PATH