Automatic dependency submission (NuGet) cannot be used on a .NET monorepo: .slnx, 20-project cap, non-root manifests, and preview SDKs

[glen-84]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

Supply chain security

Discussion Details

We want Dependabot alerts (not PRs) for the NuGet dependencies of a public .NET monorepo. The static dependency graph cannot provide them because the repository uses Central Package Management, and the recommended replacement, automatic dependency submission, cannot run on this repository for four independent reasons.

Repository shape

• Public .NET monorepo, 350 .csproj files under src/.
• Central Package Management: every version lives in src/Directory.Packages.props; no PackageReference carries a Version.
• Solutions are .slnx files under src/ (e.g. src/All.slnx). The repository root contains only global.json and nuget.config.
• global.json pins 11.0.100-preview.6.26359.118 with rollForward: latestMinor.
• No dependabot.yml; version-update PRs are not wanted.

Why the static dependency graph is not enough

The SBOM for this repository lists 157 NuGet packages, 8 of them with a version. The static parser reads .csproj files and does not resolve versions from Directory.Packages.props, so nothing can match an advisory. This is the behavior reported in Dependency graph does not find NuGet package versions when using Central Package Management and in dependabot/dependabot-core#10772, where the dependency graph team's answer (2026-03-11) is to use automatic dependency submission.

Why automatic dependency submission cannot run here

The observations below come from the run log of the generated Automatic Dependency Submission (NuGet) workflow and from the automatic dependency submission reference.

1. Trigger requires a root-level manifest or a dependabot.yml nuget entry. The supported list is .sln, .csproj, packages.config, .vbproj, .vcxproj, and .fsproj; .slnx is not included, and this repository has none of them at the root. Adding a dependabot.yml nuget entry only to satisfy the trigger creates a version-update job that we do not want, even with open-pull-requests-limit: 0.

2. Project discovery ignores .slnx and stops after 20 files. The generated validate-project step runs:

   project_files=$(find . -type f \( -name "*.csproj" -o -name "*.sln" -o -name "*.vbproj" -o -name "*.vcxproj" -o -name "*.fsproj" \) | grep -v '/obj/' | grep -v '/bin/' | head -20)

   and then runs dotnet restore on each result. On a repository with 350 project files this restores 20 of them, so component-detection finds project.assets.json for 20 projects and the submitted snapshot silently covers a fraction of the dependency tree. The step summary reports the files it found but not that the list was truncated.

3. SDK support is documented as .NET 8.x, 9.x, and 10.x only. The workflow checks for a root global.json and otherwise installs 8.0.x, 9.0.x, and 10.0.x. The documentation does not say whether a global.json that pins a preview SDK (here .NET 11 preview 6) is honored, and there is no way to find out short of enabling the feature and reading the failed run.

4. Restore runs per project file, not per solution. Even without the cap, restoring 350 projects one at a time is far slower than dotnet restore src/All.slnx, and there is no way to point the workflow at a solution or exclude directories (the only configuration is the on/off toggle).

Requests

• Trigger on a supported manifest anywhere in the tree, since the workflow already scans the whole tree, and add .slnx to both the trigger list and the find pattern.
• Remove the head -20 cap, or emit a warning when it truncates, and let repositories configure the restore entry points (solution or project paths) and directory exclusions.
• Honor the SDK version in global.json, including preview versions, and document it.
• Longer term, resolve PackageVersion entries from Directory.Packages.props in the static dependency graph, which would remove the need for a restore-based submission on CPM repositories altogether.

Drafted by Claude (Anthropic AI assistant).

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[iawaisahmd]

the silent head -20 truncation seems like the biggest issue here. even before supporting larger monorepos properly, the workflow should at least fail or show a clear warning when more than 20 projects are found. silently submitting a partial dependency snapshot could give maintainers the impression that their full dependency graph is being monitored when it isn't.