Ship stripped cdac AOT binary and its symbols in the transport package

[hoyosjs]

Why

On Linux and macOS the mscordaccore_universal (cdac AOT) binary shipped in the Microsoft.DotNet.Cdac.Transport package was unstripped, and no debug symbols were being added to the symbol packages. Diagnostics tooling consuming this transport package got a fat binary with no separate symbol file.

Root cause

The package's <File> entry pointed at $(DotNetCdacBinDir), the NativeAOT publish directory. That output is intentionally unstripped, and there is no symbol file next to it.

The runtime-component build (src/native/managed/native-library.targets) already does the right thing: it strips the binary the same way the CoreCLR cmake build does and installs both the stripped library and its symbol file (.so.dbg / .dylib.dwarf / .pdb) into the CoreCLR artifacts directory. Nothing was consuming that stripped output.

Change

Point the transport package at $(CoreCLRArtifactsPath) (where the stripped binary and symbol are installed) instead of the publish directory. Switching the entry from a bare <File> to a <NativeBinary> item lets the existing packaging infrastructure (GetSymbolPackageFiles in src/installer/pkg/projects/Directory.Build.targets) auto-discover the adjacent symbol file and add it to the symbol package, matching how Microsoft.NETCore.DotNetAppHost and other native packages work.

This is deliberately surgical: the custom cmake-matching strip logic (including the macOS codesign step) is left untouched; only the package now consumes the stripped output plus its symbol.

Note

This PR was authored with assistance from GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR updates the Microsoft.DotNet.Cdac.Transport packaging project to source the mscordaccore_universal native artifact from the CoreCLR artifacts output (rather than the NativeAOT publish output) and to model it as a NativeBinary so the existing packaging targets can discover and include the adjacent symbol file in the symbol package.

Changes:

• Switch the package input from $(DotNetCdacBinDir) to $(CoreCLRArtifactsPath) for mscordaccore_universal.
• Use a NativeBinary item (then include it via <File Include="@(NativeBinary)">) so GetSymbolPackageFiles can auto-pick up .so.dbg / .dylib.dwarf / .pdb.

Comments suppressed due to low confidence (1)

src/installer/pkg/projects/Microsoft.DotNet.Cdac.Transport/Microsoft.DotNet.Cdac.Transport.pkgproj:22

• The <File> item group should be conditioned on $(PackageTargetRuntime) being set (consistent with other native packages like Microsoft.NETCore.DotNetAppHost). Without this, building the pkgproj directly with an empty PackageTargetRuntime would produce an invalid TargetPath like runtimes//native and also bypass symbol discovery (which is already gated on PackageTargetRuntime!='').

  <ItemGroup>
    <File Include="@(NativeBinary)">
      <TargetPath>runtimes/$(PackageTargetRuntime)/native</TargetPath>
      <IsNative>true</IsNative>
    </File>
  </ItemGroup>