Provide API to get ListRuntimes and ListSDKs output

[nagilson]

Is your feature request related to a problem? Please describe.

The debugger would like to reuse our logic to get the architecture and installations so they don't use dotnet --info. We can share this info via an API available in version 2.3.7 as follows:

Command:

`dotnet.availableInstalls` 

Takes:

export interface IDotnetSearchContext :
{
mode : DotnetInstallMode // (`runtime` | `aspnetcore` | `sdk`) The 2 runtime modes behave the same and return both runtime types.
dotnetExecutablePath : string, // A full path is preferred, as 'dotnet' will fail if 'which' or 'where' is corrupted.
architecture : string | null // (accepts 'x64', 'x86', 'arm64'). Will default to the executable architecture if detectable, else the `os.arch()`.
}

Returns:
IDotnetListInfo[], empty if none found

export interface IDotnetListInfo
{
 mode: DotnetInstallMode, 
version: string, 
directory : string, 
architecture: string | null // Architecture is null if it cannot be determined, which should not happen except in cases such as: a dotnet executable built for arm32 or custom architecture such as `Silicon Graphics SVx`, or a corrupt dotnet executable.
}; 

A clear and concise description of what you want to happen. Include any alternative solutions you've considered.

Utilize our cache and architecture API to reduce load.

Describe the solution you'd like

dotnet/vscode-csharp#8370 (comment)

Additional context

cc @baronfel for FYI

[JoeRobich]

Can we make dotnetExecutablePath optional? Also, it might be useful to include the path to the dotnet CLI as part of the results.

[WardenGnaw]

+1 with making dotnetExecutablePath optional.

The debugger is just looking for the sdk in the PATH used to determine what built the debuggee to figure out what kind of architecture it needs to debug.

[nagilson]

In this case, would we utilize our logic for finding dotnet, dotnet.findPath? I like this idea, and happy to include that as well.

We could call both dotnetPath : string (|undefined on the context) to match the existing APIs. Perhaps we should, though it might be confusing to users who dont know the distinction between the host/executable vs a runtime or SDK.

[nagilson]

+1 with making dotnetExecutablePath optional.

The debugger is just looking for the sdk in the PATH used to determine what built the debuggee to figure out what kind of architecture it needs to debug.

This would be different from the findPath API. findPath will return the VS Code setting for runtime lookup above all else, but not SDK lookup. It will also search other locations besides the PATH, if PATH is invalid. If we should simply use the PATH, we can do that.

[nagilson]

If we utilize only PATH:

• If the debugger calls findPath to get the executable they want, they may find a valid executable.
• If they call availableInstalls, it may not find dotnet. Then the result would be null for the arch, so it would likely fail?

If we utilize findPath:

• Under the 'runtime' mode we would only find the vscode setting runtime unless a versionSpec is used.
• We would need some sort of requirement for the versionSpec. We could default to accepting any SDK. Though this may result in discrepancies, if the dotnet executable on PATH is not sufficient for the versionSpec used to find dotnet above. In the worst case, they could provide conflicting information.

Both of these scenarios have me concerned with this approach. I would lean towards utilizing findPath and then requiring a versionSpec on this command as well, just like that command does.

[WardenGnaw]

If they call availableInstalls, it may not find dotnet. Then the result would be null for the arch, so it would likely fail?

Thats ok, we would fall back to asking the user to provide the target architecture if we can't find dotnet

We would need some sort of requirement for the versionSpec. We could default to accepting any SDK. Though this may result in discrepancies, if the dotnet executable on PATH is not sufficient for the versionSpec used to find dotnet above. In the worst case, they could provide conflicting information.

Yeah, if I'm understanding correctly, can put in something like >6.x and it would give us the highest version SDK?
Today we just check to see the version of the dotnet to see if its >6.0 to see if it supports arm64, else we say its x64.

If we have a dotnet, we check the RID for the architecture.

cc @gregg-miskelly

[nagilson]

Is this how the debugger currently behaves? Utilizing the .NET on the PATH? It is not calling findPath? If so, I am less concerned with this situation.

To check the architecture, we read the COFF/PE/ELF/MACHO binary header, utilize --list-runtimes --arch if available (and after .NET 11), and in the worst case call --info. The first approach should always work however, excluding the scenarios stated above.

[WardenGnaw]

The goal of the debugger is to use the same dotnet the customer used to build (or run) their .NET project, which we assumed would be the one in PATH.

[nagilson]

I see, so currently it uses the PATH. I think this is good for this scenario. I do worry that this would reintroduce the problem of different components of the product resolving dotnet in different fashions. However, the dotnet that you need to resolve is different from either the SDK for CPS or the runtime for C# to run under. I think I will caveat the proposal with a warning that most people should be defining the executablePath.