How To Find Out Which NuGet Packages Depend on Yours

Renaming a package ID is a potentially destructive action and one we don’t recommend doing. Why? Well if any other packages depend on your package, you’ve effectively broken them if you change your package ID.

For example, today I wanted to rename a poorly named package, MicrosoftWebMvc, to Mvc2Futures. What I ended up doing is recreating the same package with the new ID and uploading it. That way existing packages that depend on MicrosoftWebMvc aren’t broken.

But now, I have two packages that have the same functionality, but different IDs. Wouldn’t it be nice to eventually remove the old one? I guess I could if I knew that no other package had a dependency on it.

This is where the benefit of having an OData service over the packages in the gallery comes in quite useful. It allows us to construct ad-hoc queries we hadn’t accounted for in our API via an URL. Here’s the URL that shows me a list of all packages that depend on MicrosoftWebMvc.

http://packages.nuget.org/v1/FeedService.svc/Packages?$filter=substringof(‘MicrosoftWebMvc’,%20Dependencies)%20eq%20true&$select=Id,Dependencies

Notice that we’re searching the Dependencies node for the substring “MicrosoftWebMvc” anywhere in it. If my package ID was “web”, this would not be a good query to run, so you might need to tweak it for your use case.

Also, this query only detects direct dependencies. It doesn’t detect transitive dependencies. However, in this case, that’s good enough for my needs.

With this list in hand, I can now approach the MvcContrib folks (who are the only ones that depend on it), and suggest they update their existing packages in place to point to the one with the new ID.

If they do this, am I safe to delete MicrosoftWebMvc?

Not necessarily.

I really need to think twice before I remove the MicrosoftWebMvcpackage because it’s already been downloaded 939 times. For those users who’ve installed it into their applications, they’ll never get updates for that package.

In this particular case, this is not a problem because we never plan to update the Mvc2Futures package. But for a package that’s more widely used and frequently updated, this would be a bigger concern.

In the meanwhile, what I will do is update MicrosoftWebMvc to be an empty package that depends on the correct package. That’s probably a good plan while I wait for packages that depend on it to update.

Comments

12 responses

Damien • February 23rd, 2011
Of course, that only finds public packages that are in the main gallery. It can't find any packages that have been privately built and shared.

Janier Davila • February 23rd, 2011
Can a package “impersonate” another? Meaning, can you download Mvc2Futures but make everyone believe it is actually MicrosoftWebMvc. Then you can get rid of MicrosoftWebMvc.
It is very easy to guess that my knowledge of Nudget and Packages is very limited. This just poped up to my head while reading your article.

Bradley Landis • February 23rd, 2011
Is there a way to deprecate packages in NuGet? The update system could then be used to alert the users to the deprecation and point them toward the replacement package.

Shane Whittet • February 23rd, 2011
Feature request: What Bradley Landis said:)

Zhila • February 23rd, 2011
You could implement something similar to APT, where, in addition to listing dependencies, it can list conflicting packages and provided packages, e.g. package Mvc2Futures provides MicrosoftWebMvc, allowing packages that depend on MicrosoftWebMvc to actually depend on Mvc2Futures. This would also allow different packages which provide near equal functionality to all provide the same dependency, allowing a person to choose his favorite one (with said project also depending on a default package to limit requiring choice), and conflict system will prevent different packages with known incompatibilities from installing side by side. But, maybe in the end, this is just too much overkill.

John Ludlow • February 24th, 2011
Janier kind of beat me to this but I was thinking you need some kind of alias functionality. That is, change the package name to Mvc2Futures, add an alias named MicrosoftWebMvc.
Coupled with the ability to mark packages obsolete (Brian's suggestion), this should cover most of the common scenarios.

Martin • March 1st, 2011
Thanks for adding Mvc3Futures (as prevously requested). :)

Matt S. • March 3rd, 2011
I'm all for adding a new feature to NuGet that allows a package to "redirect" to another. Anyone trying to download the deprecated package would be redirected to the new one. Likewise, updates would pass from the new package down to subscribers of the old one following the redirect in reverse.

Andrew Arnott • December 6th, 2016
I've written a powershell script that does this, and prints out a table of the nuget packages for easy human parsing: https://gist.github.com/AAr...

Robert Harvey • August 28th, 2019
I get ‘Resource not found’ when clicking on your Url.

AroglDarthu • October 30th, 2019
Unfortunately the OData stuff is (being) deprecated in the API V3 of NuGet. Any ideas on how to get this dependency information now?

AroglDarthu • October 30th, 2019
BTW: the V1 url seems to be working at the following location https://www.nuget.org/api/v1/feedservice.svc/Packages?$filter=substringof(%27MicrosoftWebMvc%27,%20Dependencies)%20eq%20true&$select=Id,Dependencies

Would be nice to get the response back in JSON though. Would be even nicer to query this on the API V3.