fix: NU1004 false positive when P2P has no compatible TFM in locked mode

[PHILLIPS71]

Bug

Fixes: NuGet/Home#12010

Description

IsLockFileValid unconditionally invalidated the lock file (NU1004) whenever a P2P project had no compatible target framework.

This was incorrect, restore itself produces zero transitive dependencies for such a P2P, so a lock file entry with empty deps is consistent with what restore would produce and should be accepted as valid.

The fix guards the invalidation on whether the lock file entry contains any dependencies:

• Empty deps: valid; no NU1004 raised.
• Non-empty deps invalid; the entry is stale from when the P2P previously had a compatible TFM.

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc.

[PHILLIPS71]

@dotnet-policy-service agree

[nkolev92]

Hey @PHILLIPS71

Thanks for creating this PR.

I'm not sure I agree with your assessment that this is a false positive, but I'll check with some of my teammates as well.

I think it's fine if NU1004 is raised here.
The project dependencies have changed and that's all NU1004 is supposed to change.

Moreover, I'm not sure this actually tackles the problem in the linked issue, which is really about AssetTargetFallback not being applied through project refs when calculating.

[dotnet-policy-service]

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 30 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.