Pack dotnet-sos/dotnet-debugger-extensions as AOT tool

[am11]

With .NET 10, we can now leverage the standard convention of separating the 'root package' from the 'runtime package' when building AOT tools.

This scalable model allows us to replace the current monolithic infrastructure and its hardcoded list of Microsoft-supported platforms. By adopting this approach, we can easily accommodate community-driven and emerging platforms.

---

Tutorial: Building a Native AOT Tool

$ echo 'using static System.Runtime.InteropServices.RuntimeInformation;
Console.WriteLine($"{OSDescription}\n{FrameworkDescription}");' | dotnet run -

Alpine Linux v3.23
.NET 10.0.8

$ dotnet new console -n myaottool
$ cd myaottool

Program.cs

using System;

Console.WriteLine("Hello from a Native AOT .NET Tool!");
Console.WriteLine($"Running on: {Environment.OSVersion}");

myaottool.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <Nullable>enable</Nullable>
    <PackAsTool>true</PackAsTool>
    <PublishAot>true</PublishAot>

    <ToolPackageRuntimeIdentifiers>
      <!-- Windows -->
      win-x64;win-x86;win-arm64;
      <!-- Linux -->
      linux-x64;linux-arm;linux-arm64;
      linux-musl-x64;linux-musl-arm;linux-musl-arm64;
      <!-- macOS -->
      osx-x64;osx-arm64;
      <!-- Current RID (for community/custom platforms) -->
      $(RuntimeIdentifier)
    </ToolPackageRuntimeIdentifiers>
  </PropertyGroup>

</Project>

The runtime tool is now a standalone package. Note that separate builds are required for each supported platform to generate the necessary runtime artifacts.

# Pack the root package
$ dotnet pack -c Release

# Pack the runtime-specific package (for the current platform)
$ dotnet pack -c Release --ucr

$ find . -name '*pkg'
./bin/Release/myaottool.linux-musl-arm64.1.0.0.nupkg
./bin/Release/myaottool.1.0.0.nupkg

We can now push this nupkg to nuget from each "official" machine. The community guys can just place their runtime pack to <sdk path>/library-packs in their builds.

test and verify locally (does it work, is it really AOT app etc.):

$ dotnet tool install --global --add-source bin/Release myaottool

$ myaottool 
Hello from a Native AOT .NET Tool!
Running on: Unix 6.12.76.0

$ readelf -p .comment $(realpath $(command -v myaottool))
String dump of section '.comment':
  [     0]  GCC: (Alpine 15.2.0) 15.2.0
  [    1c]  clang version 20.1.8
  [    31]  .NET: ilc 10.0.8-servicing.26229.119+94ea82652cdd4e0f8046b5bd5becbd11461482ca

[am11]

cc @hoyosjs, @jkoritzinsky, @akoeplinger

this way, we won't be stuffing all runtime artifacts in one big nupkg https://nuget.info/packages/dotnet-debugger-extensions/10.0.721602 (see RID subdirs under tools/) and it will align with "how runtime infra deals with platform specific artifacts".

Alternative to #5495.

[hoyosjs]

This is something we are aiming for long term. It's not the highest priority right now since diagnostics can move things after branch lockdown. I also don't know if downlevel SDKs support the tool transitive restore, so we'd need to wait for that (haven't fully tested that).