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

PackageReference in csproj should identify preferred feed #9799

Closed
MV10 opened this issue Jul 15, 2020 · 1 comment
Closed

PackageReference in csproj should identify preferred feed #9799

MV10 opened this issue Jul 15, 2020 · 1 comment
Labels
Resolution:Duplicate This issue appears to be a Duplicate of another issue Style:PackageReference

Comments

@MV10
Copy link

MV10 commented Jul 15, 2020

I am proposing that the NuGet <PackageReference> tags in csproj should optionally identify the preferred package source.

The restore behavior today is essentially random unless you carefully control which feeds are active and which are inactive on a project-by-project basis. Without carefully reviewing logs, you can't even tell where a package came from after the fact. Combine this with an automated build pipeline and it's a recipe for disaster. Worse, if you need two feeds and they both happen to contain variations on the same package, you have zero control of where the build sources the package.

Where I work (very large enterprise, thousands of developers) we have many internal package sources dedicated to copies of public feeds, various in-house dev, testing, and release feeds, and so on. We also have thousands of project-specific feeds. On occasion, some of us doing R&D work even activate truly-public feeds. VS in a typical developer environment will list 10-20 feeds. It is not unusual to have duplicate packages in multiple feeds -- or worse, someone has published a package for their own project that "hides" an official package by the same name.

It's enough of a hassle that I tend to just pull packages down by hand and reference a local-path feed, apart from extremely well-known dependencies like Microsoft.* packages.

(This same scenario -- many package sources -- was also the driver for something I requested many years ago: the ability to control the search order of package sources. A fundamentally different request of course, but still badly needed. Figured it can't hurt to mention it again.)

@nkolev92
Copy link
Member

Dup of #6867

@nkolev92 nkolev92 added Resolution:Duplicate This issue appears to be a Duplicate of another issue Style:PackageReference labels Jul 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution:Duplicate This issue appears to be a Duplicate of another issue Style:PackageReference
Projects
None yet
Development

No branches or pull requests

2 participants