Use .NET Install Tool for debugger runtime lookup

[dibarbet]

See https://github.com/dotnet/vscode-csharp/issues/8312#issuecomment-2902970817 for more info

We should work with the .NET Install tool extension to provide an API we can use to look up the installed SDK architecture, instead of manually querying dotnet info.

Code to potentially remove: https://github.com/dotnet/vscode-csharp/blob/ff6e65a14cedf55fe930f36e685564a4d5780086/src/shared/utils/getDotnetInfo.ts#L14

[WardenGnaw]

@nagilson Is there an API now that we can use or is there an issue we can track for the install tool to depend on before we can start work on this?

[nagilson]

There is not yet. I will write up a proposal. It turned out to be not too hard to read the file header binary to get the architecture, so we have a very robust way to do this now.

[nagilson]

Please see https://github.com/dotnet/vscode-dotnet-runtime/issues/2315, does this seem sufficient for your use case?

[gregg-miskelly]

I am not sure we would want to do this -- the primary reason the extension is calling dotnet --info is just to make sure that dotnet is on the path.

[nagilson]

I am not sure we would want to do this -- the primary reason the extension is calling dotnet --info is just to make sure that dotnet is on the path.

dotnet --info is cached by our extension and that information is shared across extensions. The logic for determining the architecture is also written in a more efficient fashion and shared that way. The logic is consolidated and ensures the correct dotnet is used if it exists, though that is different from whether there is one on the PATH.

cc @JakeRadMSFT

[nagilson]

https://github.com/dotnet/vscode-csharp/blob/a15a562c9a9e20276b3f3da03e58d3615f4bf5d1/src/coreclrDebug/util.ts#L83 This hard-coded parsing of dotnet --info is causing some issues for customers on Mac OS. I would encourage prioritizing the issue and migrate to our APIs to find the dotnet executable.

[gregg-miskelly]

This hard-coded parsing of dotnet --info is causing some issues for customers on Mac OS. I would encourage prioritizing the issue and migrate to our APIs to find the dotnet executable.

What are the issues, and are these problems that are going to happen anyway because now their app will not be able to find dotnet when it runs?

[nagilson]

On Mac OS when the non native SDK is installed, or a custom zsh configuration is used, the PATH is not set, so dotnet cannot be found. Moving to the new API will allow us to search the hard-coded system locations for the install, which should allow it to be found. That's besides just the performance benefits. There are other issues in finding dotnet such as homebrew and snap that the API resolves properly, and can return a PATH to use where the current logic would fail.

The linked issues are examples of the top issue.

are these problems that are going to happen anyway because now their app will not be able to find dotnet when it runs?

Looking at https://github.com/dotnet/vscode-csharp/blob/a15a562c9a9e20276b3f3da03e58d3615f4bf5d1/src/coreclrDebug/activate.ts#L52 I think it should still work. The dotnet app host which runs the runtime can check the system install locations and doesn't just rely on the PATH. For evidence of this, please read https://learn.microsoft.com/en-us/dotnet/core/compatibility/deployment/7.0/multilevel-lookup#new-behavior. I can't say for 100% without just implementing it myself, but I'm pretty sure this would fix some of these issues.