Is there a way to block a package from being included?

[StingyJack]

Originally opened here (please figure out how to transition issues between content and product without burdening your customers with "paperwork" they should not be responsible for doing).

From the original... I dont want some packages to ever be installed. And I dont see a way in here to exclude it without adding it and setting an allowed version of almost nothing, and that would probably not work.

[jainaashish]

No, there isn't a way. Please explain your scenario here and then we can take it forward based on community feedback.

[StingyJack]

Specifically, I want to prevent the System.Collections.Immutable package versions greater than 1.3.1 from being included. If the package is already installed I can use allowedVersions to restrict it If its not yet installed I dont have a way to prevent it.

I want to prevent that as versions after that are netstandard target and bring a ton of baggage .

[StingyJack]

@jainaashish - I also want to block the installation of the many Microsoft.ReportViewer packages that aren't the one that is MSFT issued. Or consider that dependency satisfied if the MSFT official reportviewer package is already installed,

EDIT: And I need this all to be non-package reference format required.

[jainaashish]

If its not yet installed I dont have a way to prevent it.

If I'm not wrong here you're asking to prevent some packages bring some specific transitive dependencies. If that's the case then most likely the original package will be broken in absence of those transitive dependencies. Restricting those transitive dependencies to a certain version ranges (through AllowedVersions) still allows the original package to satisfy those dependencies, although there still might be some cases where it brakes because original package needs something specific from higher versions of those transitive packages.

So IMO if you already knows the list of packages you want to restrict because of any reason, then best course of action is to explicitly install them with specific AllowedVersions range.

I also want to block the installation of the many Microsoft.ReportViewer packages that aren't the one that is MSFT issued. Or consider that dependency satisfied if the MSFT official reportviewer package is already installed,

Are these the same packages from different authors? or similar but slightly different names? May be little more details will help understand it better. But in general, you may want to look into configuring Trust Policies at client side to only allow certain trusted authors/ repositories to install packages, which might also help with your concerns. Look at https://blog.nuget.org/20181205/Lock-down-your-dependencies-using-configurable-trust-policies.html

[StingyJack]

For the System Colllections Immutable package specifically I've just about done that with a majority of my projects, but they were going to be consuming that package anyway. In this case I want to stop the "whoops" upgrade from happening that brings along a netstandard dependency and litters a project with about 100 dependencies that has no plans to leave netfx (many developers see an upgrade available that isnt breaking and just take it, so part of this is on the S.C.I authors for not bumping the major version when going netstandard with the package).

Going this route could lead to a lot of potential packages to preinstall, and not dragging a lot of extra useless dependencies is kind of the point of wanting to block the installation/upgrade. Being able to specify the blocked package in a nuget.config for the branch/solution would be nice too, but I guess in the meantime I'll have to add in a script task to the gated checkin build to just fail the checkin if one of the known netstandard packages is present.

Its historically been difficult to find the right Report Viewer control. Searching finds all kinds of packages that users like me have put together using official MSFT libraries and uploading those packages. So for a few years we had installed one or two of those and they are everywhere in our codebase. They aren't malicious, but we've found the correct Report Viewer package and have started using that. The problem is that many of the existing packages that are used as components in other programs we have built, and that older report viewer package wants to come along into the new programs that already have the new control installed.

For this one I was looking to either block the old package or instruct nuget on an acceptable package pedigree (Package A v 1.2 upgrades can be satisfied by Package B v 2.6 or later) for any projects in the solution/branch or across an organization

[zkat]

@anangaur @chgill-MSFT please note this and whether it's something we'll prioritize. :)

[kasperk81]

moq with sponsorlink is a current example of such a fiasco where this feature can help https://github.com/moq/moq/issues/1372. moq, after achieving its half a billion downloads glory, has decidedly turned into a ransomware and a spyware. since the owner is insisting on it, we don't trust this package and would never want moq to be installed explicitly or transitively. see https://github.com/dotnet/docs/pull/36638

[Atulin]

Not gonna lie, being able to configure the project or Nuget as a whole to never allow anything that has SponsorLink as a transitive dependency to be installed, does sound good

[nkolev92]

Hey all, I see a bunch of upvoted comments here, but just a reminder that in order to increase visibility of asks, you should upvote the main issue body instead: https://github.com/NuGet/Home/blob/dev/Issue-Triage-Policy.md#up-voting-a-feature-requestbug.

[StingyJack]

Hey all, I see a bunch of upvoted comments here, but just a reminder that in order to increase visibility of asks, you should upvote the main issue body instead

@nkolev92 - how come you guys don't count this stuff right yet? It's misdirecting your product efforts.