Related #98735, though this is not as comprehensive.

dotnet --list-sdks and dotnet --list-runtimes are very helpful tools, but they do not provide information about the architecture of said installations of the SDK and Runtime. This has been problematic for us in the C# and C# DevKit extension when we are trying to determine whether a PATH is a valid install of the SDK or Runtime for us to use for a given situation.

For example, this is a problem and a blocker for us in dotnet/vscode-dotnet-runtime#1954.

dotnet --info is unreliable in its architecture output. Sometimes it does not print the architecture (e.g. install script standalone runtime with a host prints no arch in dotnet 3.1.) It is also a non-machine readable format. Sometimes, it is incorrect #108502, though that has been fixed; it would not apply to all API calls for older hosts.

We should Enable an optional architecture argument such that if an architecture is specified, dotnet lists the runtimes/SDKs for that architecture instead of the current dotnet architecture. For example, dotnet --list-runtimes --architecture x86.

Of course, other non-breaking options such as a new command also suffice.

Via @joeloff, technically this information may be available in the COFF Header of the DLLs and read the machine type from that. It's tricky though, because on Windows it would be a PE binary and on non-Windows it would be an ELF binary. Especially in nodejs, it will be taxing to consider endianness amongst other things to try to determine this.

RE the implementation : If you read something like System.dll, which should always be a PE file, then reading the COFF header should suffice.

system.dll --> runtime
dotnet.dll --> sdk
system.drawing --> desktop

This is a request that has been made several times internally from others below as well.
Having such a feature would allow us to improve stability in C# for VS Code.

cc @baronfel @elinor-fung @agocke @AArnott @lifenglu @marcpopMSFT @arkalyanms