Include `dotnet-sos` in source-build

[am11]

dotnet-sos comes with libSOS for MSFT supported platforms: https://nuget.info/packages/dotnet-sos/9.0.621003. During the source-build, it doesn't get built. We should build the nupkg and include it under <install prefix>/library-packs so dotnet tool install --global dotnet-sos picks it up from the bundle on community platforms like linux-riscv64.

Proposed actions:

• in diagnostics repo: remove SourceBuildManagedOnly from https://github.com/dotnet/diagnostics/blob/22431fb5bfe047454e652a7274f4b4bc4b367527/eng/DotNetBuild.props#L6
• in SDK repo: add it to the bundled package

  sdk/src/Layout/redist/targets/RestoreLayout.targets

  Line 79 in e5f35a2

  <ItemGroup>

cc @mikem8361, @hoyosjs

[MichaelSimons]

[Triage] It appears the proposal is to not only build this in source-build but to also add it as a new bundled global tool. We would want the same behavior across source build and the Microsoft build. @baronfel - do you have any thoughts on this?

[baronfel]

Minor size concerns (we get pushback from users on SDK download sizes), and if we add this then we'd want to add it to the list of built in tools (like watch, format, etc) that the SDK knows how to involve without being externally installed.

cc @marcpopMSFT

[am11]

The package on nuget.org is 10 MB in size because it has all official supported runtimes. This approach is very wasteful and it can be avoided if they switch to runtime.json based model, i.e. per-runtime-package with single binary and a meta (or unsuffixed) package having a single runtime.json file.

However, it won't be a problem for source-build, as it only builds for single runtime at a time, which is around 1 MB in size. Current SDK from VMR main for linux-riscv64 is 476MB https://github.com/am11/dotnet-riscv/actions/runs/14571025407, so it would only be a 0.21% increase. This buys us debugging experience of managed code with VS code and lldb command line etc.

[MichaelSimons]

[Triage] Gentle ping @marcpopMSFT - do you have any input here?

[marcpopMSFT]

The suggestion is to include it has a built-in but the source still lives in the sos repo, correct? Since we have the VMR now, we can include in the source build and the product build without as much concerns about codeflow per my understanding. If the built-in did correctly result in closer to 1MB as listed above, no concerns. 10MB isn't too bad but it sounds like there's a lot of duplication and we're already discussing options for trying to reduce that duplication.

Who would be in charge of keeping it up to date? Would it have to be updated in servicing as well? Does it frequently have security issues requiring special updates?

[am11]

Who would be in charge of keeping it up to date? Would it have to be updated in servicing as well? Does it frequently have security issues requiring special updates?

VMR already builds the diagnostics repo, but skips over native lib due to the aforementioned condition. I think we can keep the same cadence and enable the native build. Total build time in CI with managed+native code is 4 minutes and the cmake part (build.sh --skipmanaged) took 34seconds on my machine (osx-arm64); so the time impact is also, almost, negligible.

Naively, the security patches do not seem too frequent https://github.com/search?q=repo%3Adotnet%2Fdiagnostics+security&type=commits but I think they follow the existing release process (native artifacts are not treated separately in that regard AFAICT). libSOS basically implements llvm debugger (lldb) interface in C++ to provide managed code debugging on Unix-like platforms.

[MichaelSimons]

@marcpopMSFT - This looks pretty straight forward. Enable dotnet-sos in the diagnostics source build graph and add it as a built-in global tool.

One open question I have is around how difficult it will be to add sos to source build? What dependencies does it have that are not already included in source build. This would be easy to answer by just enabling it for source build and running a build.

[MichaelSimons]

@baronfel, @marcpopMSFT - I see you two as the final decision makers here as this affects the SDK. Can you provide your input? TIA

[baronfel]

I'm happy to have it - the size impact seems quite small compared to the debugging aid.

[MichaelSimons]

[Triage] Transferring to the SDK as this is really an SDK issue at this point - Add SOS as a bundled tool and include it in source-build.