Package dependancy resolution in NuGet and naming conflicts

Question

On my team at work we rely on two NuGet feeds: the offical one from NuGet.org for public packages and a folder on our file server for internal packages.

This has worked well for us, but I think we have a potential problem. It looks like NuGet resolves dependencies based on package name and version number. With only one feed in play, this doesn't seem like a problem. With more than one feed, there's a risk of a name conflict. Based on NuGet's resolution rules, it looks like it will pick the highest version number, regardless of feed.

This leaves us in a bit of a spot. It's not likely to happen, but if someone were to publish a package on the NuGet.org feed that had the same package name as one on our internal feed, we could end up including an unexpected package.

I can think of two ways to work around this:

1) Pull the packages we rely on into our private feed. While this is doable, it's not terribly appealing because of the management burden of constantly downloading package updates into our private feed.

2) Publish a placeholder package via the NuGet.org feed to reserve the package name. This seems like it would work, but feels like a hack to me.

Is there a better way?

Thanks for your help!

Answer 1

This could be accomplished quite easily with our product ProGet (essentially it's a private NuGet repository with additional features), though the feature to do so is only available in the paid edition. Essentially what you would do, is point only to the ProGet hosted feed from within Visual Studio. By default, ProGet feeds are connected to the official NuGet.org feed and are able to download all packages in the official feed as well.

However, if you were to set up a "connector filter" of:

*
!YourPackageNameOrPrefix

then it would block packages with the same name as yours from being downloaded from the official feed.

If you aren't interested in a 3rd party solution, you could always name your packages with something that would be highly unlikely to be copied (e.g. YourCompany.XXXXX), but that of course would not prevent anyone from copying it on purpose.