[ANE-2523] NuGet: analyze every .csproj in a directory#1712
Conversation
PackageReference discovery used `find isPackageRefFile` which returned only the first match. Sibling project files in the same directory were silently dropped. Switch to `filter` so each .csproj/.xproj/.vbproj/ .dbproj/.fsproj yields its own NuGetProject.
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
WalkthroughThis PR enables NuGet package discovery to analyze all 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Changelog.md`:
- Line 7: Update the Changelog entry that starts "NuGet: PackageReference
discovery now analyzes every `.csproj`/`.xproj`/`.vbproj`/`.dbproj`/`.fsproj` in
a directory..." by appending the PR reference " (PR `#1712`)" to the end of that
line so it matches the existing entry style and provides traceability to PR
`#1712`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Pro
Run ID: 22d7394e-b7f6-4213-8b74-eb5b32f93dab
📒 Files selected for processing (6)
Changelog.mdspectrometer.cabalsrc/Strategy/NuGet.hstest/NuGet/NuGetSpec.hstest/NuGet/testdata/multi-csproj/App.Core.csprojtest/NuGet/testdata/multi-csproj/IngageWeb.csproj
ServiceStack v5.13.2 has 92 project files (91 .csproj + 1 .fsproj).
The old expectation of 64 was the count of directories that contain
at least one project file, which matched the pre-fix behavior of
`find isPackageRefFile` returning only the first project file per
directory. 19 directories hold 2-3 sibling csproj variants
(src/ServiceStack/{ServiceStack, ServiceStack.Core,
ServiceStack.Source}.csproj for .NET-Framework / .NET-Core /
source-distribution targets), and the old code silently dropped the
non-winners — that's the ANE-2523 bug. Discovery now emits one
NuGetProject per project file, so the count grows accordingly.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The explanation for why the target count goes 64 to 92 belongs in the PR description, not in the integration test body. The test reads cleaner without nine lines of context above a one-line assertion. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Overview
Discovery in
src/Strategy/NuGet.hsusedfind isPackageRefFile files, which returned only the first matching project file per directory. Any directory containing multiple.csproj/.xproj/.vbproj/.dbproj/.fsprojfiles would silently drop all siblings — and if the surviving file had no dependencies, the directory looked empty in the FOSSA report. This PR switches tofilter, mappingNuGetProjectover every match.Acceptance criteria
A directory with multiple project files now produces one
NuGetProjectper file. Single-project directories and theproject.assets.jsonshort-circuit branch are unchanged.Testing plan
cabal test unit-tests --test-options="--match=NuGet"— 132 examples pass, including the newNuGet.NuGetdiscovery spec.test/NuGet/testdata/multi-csproj/contains two.csprojfiles; the new spec asserts both are discovered.ServiceStackexpected target count goes from 64 → 92 (every project file under v5.13.2: 91.csproj+ 1.fsproj). 19 directories hold 2–3 sibling.csprojfiles (e.g.src/ServiceStack/{ServiceStack, ServiceStack.Core, ServiceStack.Source}.csprojfor the .NET-Framework / .NET-Core / source-distribution variants); the oldfind isPackageRefFilepicked one alphabetically and silently dropped the rest. The new count is every project file the bug was masking.Risks
The integration tests in
integration-test/Analysis/NugetSpec.hs(ServiceStack,dotnet-core-2.0-example,DapperAOT-CPM) assert literal target counts. If any of those fixtures contains a directory with multiple sibling.csprojfiles, the count goes up. Per the ticket: if those tests fail with higher counts, that's the bug being fixed — update the expected counts.Metrics
N/A.
References
Checklist
test/NuGet/NuGetSpec.hs).docs/references/strategies/languages/dotnet/packagereference.mdalready documents the fixed behavior ("all NuGet project files").Changelog.mdupdated under 3.17.6.