Fix NativeAOT aggregate executable dSYM publish paths

[akoeplinger]

Summary

• Preserve the metadata of each expanded aggregate executable shim dSYM entry when assigning its publish path.
• Prevent dSYM contents from collapsing to paths such as HelloExe.dSYM/HelloExe.dll, which can leave non-PE files with a .dll extension in packages.
• Extend the aggregate executable test on macOS to produce dSYM bundles and validate the expected Contents/Info.plist and Contents/Resources/DWARF paths.

dotnet/dotnet#8135 enabled publishing the ASP.NET Core NativeAOT tool symbols and exposed this issue during VMR package signing. The underlying publish-path logic came from #128553.

The resulting error was that every bundle file received the same destination:

dotnet-dev-certs.dSYM/dotnet-dev-certs.dll

The files overwrite each other, leaving a ~207-byte YAML relocation file named  .dll . SignTool classifies files by extension, passes it to PEReader and throws: System.BadImageFormatException: Unknown file format

Testing

• ./build.sh clr+libs -lc release -rc checked
• Confirmed the regression test fails with the original publish target.
• ./build.sh clr -rc release
• src/tests/build.sh -Test nativeaot/AggregateExecutableLibrary/AggregateLibrary.csproj -arm64 -release -nativeaot
• bash artifacts/tests/coreclr/osx.arm64.Release/nativeaot/AggregateExecutableLibrary/AggregateLibrary/AggregateLibrary.sh

Note

This PR description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes how NativeAOT aggregate executable shim dSYM bundle contents are assigned publish-relative paths, ensuring each expanded file under *.dSYM/** keeps its own filename/extension metadata when constructing ResolvedFileToPublish.RelativePath. It also extends the existing aggregate executable test on macOS to generate dSYM bundles and validate that the published paths match the expected dSYM layout.

Changes:

• Update NativeAOT publish logic to compute dSYM recursive publish paths using the expanded file items’ metadata (and a preserved bundle name), avoiding incorrect “collapsed” paths.
• Enable native debug symbols + publishing of output symbols for the aggregate executable test on macOS.
• Add a macOS-only validation target that asserts key dSYM files are published under Contents/Info.plist and Contents/Resources/DWARF/....

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
src/tests/nativeaot/AggregateExecutableLibrary/AggregateLibrary.csproj	Enables dSYM generation/publish on macOS for the aggregate executable test and adds validation that expected dSYM bundle file paths are present in ResolvedFileToPublish.
src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Publish.targets	Adjusts aggregate executable shim dSYM recursive item handling so RelativePath is computed from the recursively-expanded file items (with a preserved bundle-name metadata) rather than batching against the reference item metadata.

[jkoritzinsky]

Can the symbol servers resolve symbols now from dSYM bundles?

If so, we can move our native symbols for things like CoreCLR to use dSYM bundles.