You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.)
The text was updated successfully, but these errors were encountered:
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.)
The text was updated successfully, but these errors were encountered: