Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NoWarn on a package reference does not apply transitively to its dependencies #5740

Open
bording opened this issue Aug 10, 2017 · 12 comments

Comments

@bording
Copy link

commented Aug 10, 2017

If I have added NoWarn to a package reference to suppress NU1701, it only applies to the specific package and not its dependencies.

For example, in a netcoreapp2.0 project, if I have the following package reference:

<PackageReference Include="ApprovalTests" Version="3.0.13" NoWarn="NU1701" />

The warning is suppressed for the ApprovalTests package itself, but I still see a warning for the ApprovalUtilities package that it depends on:
image

I currently have to add an additional package reference to suppress that warning:

<PackageReference Include="ApprovalUtilities" Version="3.0.13" NoWarn="NU1701" />

It doesn't make sense to me that I should have to do this. If I've suppressed the warning on the package I've added to the project, it should apply to all of its dependencies implicitly since they are also referenced implicitly.

While I could work around this by globally suppressing the warning, that isn't a great solution either. That means I'll won't see the warning for any new packages I might add later.

VS Version: 15.3.0 Preview 7.0

@anangaur

This comment has been minimized.

Copy link
Member

commented Aug 10, 2017

@bording We did discuss this issue and there doesn't seem to be a clear way to fix this. Suppressing per package is meant to suppress only for that package so that the user knows the issue is only for a given package and can know about warnings in future for other package dependencies he/she adds. However, I do see this use case may not be a rare one.

May be we need another property NoWarnTransitive="NU1701" that does this trick for us? But this would mean we would move away from the standard suppression mechanism of MSBuild/C#

@mishra14

This comment has been minimized.

Copy link
Collaborator

commented Sep 28, 2017

@bording thank you for the detailed issue. You can work around this by adding a project wide no warn -

 <PropertyGroup>
    <NoWarn>NU1603</NoWarn>
  </PropertyGroup>

Please let us know if that resolves your problem or if you would still prefer a nowarn for the package closure?

@mishra14 mishra14 self-assigned this Sep 28, 2017

@bording

This comment has been minimized.

Copy link
Author

commented Sep 28, 2017

@mishra14 As mentioned on the issue already, globally suppressing the warning doesn't really solve the problem, because that will hide it for all packages, including ones I add in the future.

If I add a new package that should show this warning, then I want to see the warning so I know that I need to spend some extra time ensuring the package will work (and then add NoWarn to that package reference) or decide to not use that package after all.

@mishra14

This comment has been minimized.

Copy link
Collaborator

commented Sep 28, 2017

@bording thanks for clarifying that. I will leave this open as a design change request.

@mishra14

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2017

Assigning to @anangaur to get more clarity on the need/requirement for this feature.

@paulbatum

This comment has been minimized.

Copy link

commented Nov 22, 2017

I just want to capture that this functionality would be useful for us (azure functions team). Our dependency chain pulls in Microsoft.AspNet.WebApi.Client via Microsoft.AspNetCore.Mvc.WebApiCompatShim and we'd like to suppress this particular warning without adding a global suppression or an explicit reference. Right now we don't have a good workaround.

@anangaur

This comment has been minimized.

Copy link
Member

commented Nov 22, 2017

@paulbatum Lets say we have the following dependencies for a project:
PackageA depends on PackageC
PackageB depends on Package C

Now lets say we have a capability to suppress warning for PackageA and all its transitive dependencies. Should the suppression apply to PackageC which is also being referenced from PackageB as a transitive dependency and there is no NoWarn on PackageB?

@mishra14, Do we retain the whole dependency graph after the package dependencies resolution to be able to suppress transitively?

@paulbatum

This comment has been minimized.

Copy link

commented Nov 22, 2017

@bording

This comment has been minimized.

Copy link
Author

commented Nov 22, 2017

@anangaur I would want to see separate warnings for PackageA and PackageB. The reason is that while they both depend on PackageC, they could both use different APIs from PackageC. That would mean that using PackageA with the compat shim could be fine, but PackageB could fail.

If I don't get a warning about PackageB because PackageC is also referenced by PackageA, then I don't get any warning that lets me know I need to verify that PackageB works correctly in all the scenarios I'm using it for.

@cosminstirbu

This comment has been minimized.

Copy link

commented Apr 6, 2018

Hello,

Any news on this issue?
I'm interested in suppressing this at the package level as well.

Thank you,
Cosmin

@CaCTuCaTu4ECKuu

This comment has been minimized.

Copy link

commented Jun 12, 2019

As far as there is issue when migration from NetCore 2.1 to 2.2 you need to define Version in Microsoft.AspNetCore.App package reference (due to ef packages problems) there is no way to supress NETSDK1071 warning delicately.
Adding NoWarn="NETSDK1071" attribute doesn't work

@rrelyea

This comment has been minimized.

Copy link
Contributor

commented Jul 10, 2019

@cristinamanum @anangaur - nowarn needs to be considered for central version management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.