Support repository layouts beyond src/packages in SBOM generation

[grokys]

Summary

Follow-up to #4: extends SbomGenerator so Xpf (and any repository with a non-src/packages layout) can reuse the shared CycloneDX SBOM generation. Defaults are unchanged for the existing component-repository consumers.

What changed

• projectSearchDirs parameter on GenerateForPackage — Xpf keeps its packing projects under fork/packaging/, its SDK task project under tools/, and its winforms fork under fork/winforms/, none of which the hardcoded src/** + packages/** globs covered.
• additionalProductNames parameter — names of first-party binaries that match no constituent project id and no Avalonia.*/AvaloniaUI.* prefix (e.g. Xpf'"'"'s native wpfgfx_xpf.dll, or System.Printing.dll which ships from the System.Printing-ref project), so the package-content scan records them as manufacturer-supplied with hashes instead of flagging them as unaccounted third-party binaries.
• baseIntermediateOutputPath parameter — forwarded to cyclonedx-dotnet as -biop for Arcade-style repositories that restore into artifacts/obj/<Project>/project.assets.json. Projects not found there still resolve through cyclonedx-dotnet'"'"'s msbuild ProjectAssetsFile evaluation fallback, so mixed-layout repositories (Xpf'"'"'s fork/packaging projects use plain <projectDir>/obj) work with a single setting. Passed as a separate literal argument string because Tool'"'"'s argument handler re-quotes interpolated values — a pre-built " -biop ..." fragment gets mangled into the preceding -sv value.
• ReadPackageVersion helper — public counterpart to ReadPackageId for repositories that call GenerateForPackage directly but whose package versions are computed by MSBuild.

Known limitation (pre-existing, follow-up candidate)

Multi-RID native binaries (e.g. runtimes/{win-x64,win-x86,...}/native/foo.dll) share one assembly name and version, so the package-content scan dedupes them into a single component and only the first RID'"'"'s SHA-512 is recorded. Recording one hashed component per shipped file (keyed by package path) would be stronger CRA evidence; left out of this PR to keep existing consumers'"'"' SBOMs stable.

Test plan

• NukeExtensions.csproj builds warning-free against Nuke.Common 9.0.4
• End-to-end from the Xpf repository (AvaloniaUI/Xpf sbom branch): generated SBOMs for all four shipped packages (Xpf with 31 constituent projects, Xpf.Sdk, AvaloniaUI.Xpf.WinApiShim, AvaloniaUI.Xpf.WindowsFormsShim) against real packed output with zero warnings — every constituent located, no unaccounted binaries, wpfgfx_xpf recorded as first-party with SHA-512, nuspec-only dependencies re-added, embedded _manifest/cyclonedx/bom.cdx.json byte-identical to the standalone copy with json registered in [Content_Types].xml

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Extends the shared SbomGenerator to support repositories whose constituent projects and restore artifacts don’t follow the existing src/** + packages/** assumptions, while keeping defaults unchanged for current component-repo consumers.

Changes:

• Added optional projectSearchDirs, additionalProductNames, and baseIntermediateOutputPath parameters to GenerateForPackage to support non-standard repo layouts and Arcade-style restore layouts.
• Updated package-content verification to accept an expanded set of “first-party” binary names (constituent project IDs + optional additional names).
• Added ReadPackageVersion helper for callers that need to read the shipped package version from the .nuspec.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.