[Feature Request] Dotnet Host Should Support Programmatic Installation Architecture Scans

[nagilson]

Related https://github.com/dotnet/runtime/issues/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 https://github.com/dotnet/vscode-dotnet-runtime/pull/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 https://github.com/dotnet/runtime/issues/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

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @vitek-karas, @agocke, @vsadov See info in area-owners.md if you want to be subscribed.

[elinor-fung]

I'm reading this in two different ways, so I want to make sure I understand the request here. I can see either:

1. 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.
2. Enable an optional architecture flag such that if it is specified, dotnet lists the runtimes/SDKs of all architectures. For example, dotnet --list-runtimes --all-architectures. The output would have slightly different format (compared to without the flag) to include the architecture.

Existing command (not using the new option) continues to do the same thing - list the runtimes/SDKs of the architecture of the running dotnet.

[nagilson]

Thank you for reading this one and taking a look! 😄 This would be very helpful for us on the SDK team and also in C# DevKit. @baronfel and I have had to begrudgingly accept many teams parsing dotnet --info output because this isn't available.

I think #1 is the best option here. For those who rely on dotnet --list-runtimes and dotnet --list-sdks already but need to get more information about what's available for a specific architecture, they would have already had the parsing logic in place to do so. It also seems like it might require less work on your part?

[elinor-fung]

Yeah, (1) would be what I prefer as well, since I think it aligns more closely with the existing command.