NoWarn and transitive pinning does not play well together

[JustusGreiberORGADATA]

NuGet Product Used

dotnet.exe

Product Version

Version: 7.0.304

Worked before?

Don't think so

Impact

It bothers me. A fix would be nice

Repro Steps & Context

Hi,

Guidance for ignoring warnings with central package management enabled is to set the warnings to NoWarn in the Directory.Build.targets, as described in this comment #11952 (comment).

This works fine for me with CentralPackageTransitivePinningEnabled=false. If I turn transitive pinning on, I get problems though:

I have a project reference to a project that imports a package that cause the warning NU1701. With transitive pinning enabled I can't suppress the warning in Project A with the update gesture (PackageReference Update="Paket_that_causes_NU1701" NoWarn="%(NoWarn);NU1701").

(In Project C itself the warning is suppressed just fine.)

graph TD;
    Project_A-->Project_C;
    Project_C-->NuGet_that_causes_NU1701;

Loading

Verbose Logs

No response

[nkolev92]

Seems like a duplicate of #5740.

[JustusGreiberORGADATA]

Is it? I apply the NoWarn for the NuGet dependency inside the Directory.Build.targets, so all projects in the solution and therefore Project_A should have a direct NoWarn setting for the dependency and not (only) a transitive one. Or am I missing something 🤔? It also works just fine if CentralPackageTransitivePinningEnabled is set to false, which also does not seem to be the case in #5740.

To me it seems like the transitive pinning "creates" package references that can't be changed with the Update gesture of the PackageReference to have a NoWarn setting.

[nkolev92]

I might be missing something :)

A few behavior that should work.

• NoWarn on a PackageReference - Applies to that PackageReference only
• NoWarn in a project file - Applies to all PackageReference, direct or transitive

Something that doesn't work:

• NoWarn on a PackageReference does not apply to it's transitive dependencies, so in your case (disregard CPM), if the package referenced in project C raises an NU warning, project A, can't add NoWarn on the project and expect that to work.

Now to your example:

Pinning does effectively add a PackageReference when needed. I don't expect specifying PackageReference Update="ReferenceThatIsPinned" NoWarn="NUABCD" to work, since NuGet won't even see that item since it basically doesn't exist without an Include.

I'd expect things to work if you specified NoWarn on the project level.

Any chance you can upload a small repro here? You can always just provide the contents of the project files anonymized and provide a sample reference and let us know which warning the ref raises.

[JustusGreiberORGADATA]

Pinning does effectively add a PackageReference when needed. I don't expect specifying PackageReference Update="ReferenceThatIsPinned" NoWarn="NUABCD" to work, since NuGet won't even see that item since it basically doesn't exist without an Include.

I think that already explains why it does not work as I thought it would. I still did the small repro in this repository where changing the CentralPackageTransitivePinningEnabled enables or disables the warnings.

I'd expect things to work if you specified NoWarn on the project level.

By that, do you mean specifying the NoWarn not scoped to a package but for all packages at the same time? (If so, that does work, but for obvious reasons, it is not my favorite solution in combination with WarningsAsErrors turned on.)

My question now is: Should we mark this as a duplicate of #5740? I think a solution for #5740 would somewhat solve my problem, but I also suspect that in the WarningsAsErrors=true case, you might not always want your solution to behave as the author of #5740 wants it to. And if my suspicion is right, it is a real bummer that you can't update the package references created by transitive pinning in the same way as you could if you pinned the versions manually with a real <PackageReference include="..."> inside each project.

[nkolev92]

I think they are similar in that, you have a package whose reference is not explicitly added to the project and you want to control the assets, but different in that CPM has more of an intent since you might specify a version for a package that you never reference directly.

I think the solution is likely similar as you mentioned though.

[nkolev92]

Team Triage: Closing as dup of #5740