Rationalize short and long RIDs

[richlander]

We use two different styles of RIDs in the SDK.

% dotnet --info | grep RID
 RID:         osx.13-arm64
% dotnet build --help | grep runtime
  --use-current-runtime                Use current runtime as the target 
                                       runtime.

The dotnet --info RID includes an OS version and the --use-current-runtime one does not. That is asymmetric and confusing.

I don't have a proposal to offer right now, but want to record this issue. It should be resolved as part of dotnet/designs#260. If others have ideas, please share them.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[am11]

I think the overarching issue is that we have multiple places that compute RID, and those implementations are out of sync. They are covering different use-cases and corner-cases; sometimes by design and sometimes by accident.

RID calculated for dotnet --info is a heuristic written in C#: read a magic version file or fallback to System.Runtime.InteropServices.RuntimeInformation.RuntimeIdentifier API. That API in turn uses an AppContext switch: RUNTIME_IDENTIFIER which, if remained unset during the build of runtime package, can return "unknown"... case in point: https://godbolt.org/z/sar14E4PG)

Therefore, dotnet --info | grep RID is not the reliable source of information. e.g. for linux binaries downloaded from https://dot.net/core, one would think it would report portable RID such as linux-x64, but instead it reports non-portable RID such as ubuntu.22.04-x64 (as long as /etc/os-release file is intact). This not how that package was built, how this package is used to build apps and how this package is used to run the apps ('run' has 'similar' but not the 'same' implementation in C++ with a hardcoded fallback, which makes a difference between portable and non-portable builds behavior at application launch).