Detect NoWarn NU1701 in SDK project discovery and warn during report#15052
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds discovery-time detection of projects that suppress NuGet warning NU1701 via the MSBuild NoWarn property, and surfaces that information as a warning during discovery reporting. This improves diagnostics for cases where compatibility checks may lead Dependabot’s NuGet update flow to abandon updates.
Changes:
- Add
HasNoWarnNU1701toProjectDiscoveryResultand set it during SDK project discovery by inspecting the evaluatedNoWarnproperty. - Emit a warning in
ILogger.ReportDiscoveryfor each affected project, using a fully-normalized rooted project path and deterministic ordering. - Add a unit test ensuring the warning is logged only for projects that set the flag and that output ordering is sorted.
Show a summary per file
| File | Description |
|---|---|
| nuget/helpers/lib/NuGetUpdater/NuGetUpdater.Core/Utilities/ILogger.cs | Logs NU1701 suppression warnings per project during discovery reporting, with normalized + sorted paths. |
| nuget/helpers/lib/NuGetUpdater/NuGetUpdater.Core/Discover/SdkProjectDiscovery.cs | Detects NU1701 in evaluated NoWarn and records it on the discovery result. |
| nuget/helpers/lib/NuGetUpdater/NuGetUpdater.Core/Discover/ProjectDiscoveryResult.cs | Adds HasNoWarnNU1701 flag to carry discovery metadata into reporting/JSON. |
| nuget/helpers/lib/NuGetUpdater/NuGetUpdater.Core.Test/Utilities/LoggerTests.cs | Verifies warning emission and ordering behavior for ReportDiscovery. |
Copilot's findings
- Files reviewed: 4/4 changed files
- Comments generated: 0
ryanbrandenburg
approved these changes
May 20, 2026
Add HasNoWarnNU1701 property to ProjectDiscoveryResult that is set during SDK project discovery when the NoWarn property contains NU1701. The warning is reported once per project during ReportDiscovery using a fully normalized rooted path in sorted order. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
4c430a4 to
20b6111
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add HasNoWarnNU1701 property to ProjectDiscoveryResult that is set during SDK project discovery when the NoWarn property contains NU1701. The warning is reported once per project during ReportDiscovery using a fully normalized rooted path in sorted order.
The NU1701 warning is used to indicate that a project's target framework isn't compatible with the frameworks supported by the given package. An example might be a package that only explicitly supports
net48but a project that targetsnet10.0. A developer might do this if they have very specific knowledge about how a package is used and what may or may not work at runtime, but there is no granularity offered and dependabot has no way of knowing under what circumstances the differing target frameworks will matter or not. The likely result is that dependabot will fail to produce an update because during the compatibility checks it will find an "unsupported" package and abandon everything. With this approach we at least surface a warning so the user can easily see why no PR was generated.I initially attempted to detect the bad package pairings before the update and not re-check those later, but that opens a huge can of worms around understanding exactly why the developer added NU1701 to NoWarn to begin with and we still have no way of knowing what other interactions might cause problems or not.
Eventually we can try to improve this behavior, but with this PR there is no functional change, just more reporting about why nothing happened.