How To Find Out Which NuGet Packages Depend on Yours

nuget,, mvc, code 0 comments suggest edit

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.$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.

Found a typo or error? Suggest an edit! If accepted, your contribution is listed automatically here.



9 responses

  1. Avatar for Damien
    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.

  2. Avatar for Janier Davila
    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.

  3. Avatar for Bradley Landis
    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.

  4. Avatar for Shane Whittet
    Shane Whittet February 23rd, 2011

    Feature request: What Bradley Landis said:)

  5. Avatar for Zhila
    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.

  6. Avatar for John Ludlow
    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.

  7. Avatar for Martin
    Martin March 1st, 2011

    Thanks for adding Mvc3Futures (as prevously requested). :)

  8. Avatar for Matt S.
    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.

  9. Avatar for Andrew Arnott
    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: