Enable dotnet-sos nupkg on community platform

[am11]

https://github.com/dotnet/diagnostics/blob/8bbc63df036b0c31c865fc1ee0060564caf40f85/src/sos-packaging.props packs all Microsoft supported platforms binaries into a single package, and leaves no room for community supported platforms while doing a local dotnet-sos build by running ./build.sh -pack. Ideally, it should not "require" all binaries at least during the source-build which only care for a single target platform native lib in the nupkg.

Blocking dotnet/sdk#48986, dotnet/runtime#116293

[am11]

@jkoritzinsky, @mmitche can we share some common infra from runtime or arcade so dotnet-sos nupkg is on the same plan as rest of nupkgs produced during the source-build?

[mmitche]

I don't really know what that common infra might look like...someone from runtime will need to chime in. But yeah, it would be ideal to have a way to just pack the current rid. IMO the overall design of the package is broken if it requires complete knowledge of all supported platforms.

[steveisok]

At the very least I think we could try to make this more source build friendly. I do agree that it would be nice for all packages to be uniform.

[jkotas]

dotnet/sdk#48986 has more discussion about this.

[am11]

dotnet/sdk#48986 has more discussion about this.

SDK issue is about adding it to tarball, this is about enabling to create nuget package for community platforms regardless of source-build (diagnostics/build.sh -a riscv64 -cross doesn't pack dotnet-sos because of hardcoded list of platforms).

[hoyosjs]

The way we pack sos is that it's a global tool. Global tools - at least as of last I checked - can't restore other packages and must bundle all their dependencies. We must know the full set of things to build and pack. We have a leg that gets all different arch bits and packs them. We have not supported partial packing at all in diagnostics. This is definitely doable if the community is willing to add the infra and build SOS themselves. I don't see SOS being part of the VMR build. As for the community build of the package - the package would have a single rid and then dotnet sos install -a riscv64 would just deploy that one arch to the expected folder, but that wouldn't be included in the official MS build.

[am11]

This is definitely doable if the community is willing to add the infra and build SOS themselves.

It is about allowing current RID and skip the others (or make them optional). I'll take a look.

I don't see SOS being part of the VMR build.

Non-SB VMR builds (which MSFT builds will use in net10.0) do not need it. SB VMR build does not need it either; as long as the platform is MSFT supported (they get it from nuget.org). Community platform SB VMR build needs these few outlier packages because the experience is very poor dotnet/sdk#49241 (comment). It doesn't hurt passing an optional flag like "WithSOSPackage=true". It only serves as an enabler for half dozen non-MSFT-supported platforms. Otherwise, we will need to add a separate step in our build to rebuild diagnostics repo without -skipnative flag, untar, add the nupkg to library-packs/, and retar the SDK; i.e. an unnecessary exercise.

that wouldn't be included in the official MS build.

Yes. That is not the goal.

[hoyosjs]

A simple /p:SinglePlatformTools that takes the current RID would be Ok. I'd also add the check to dotnet-sos install.