How To Find Out Which NuGet Packages Depend on Yours

• Feb 23, 2011
• 8 Comments
• Print

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 MicrosoftWebMvc package 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.

What others have said

Damien Feb 23, 2011 7:43 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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 Feb 23, 2011 9:38 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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 Feb 23, 2011 10:27 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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 Feb 23, 2011 11:08 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

Feature request: What Bradley Landis said:)

Zhila Feb 24, 2011 2:10 AM

# re: How To Find Out Which NuGet Packages Depend on Yours

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 Feb 24, 2011 9:40 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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 Mar 01, 2011 9:11 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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

Matt S. Mar 03, 2011 10:57 PM

# re: How To Find Out Which NuGet Packages Depend on Yours

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.

What do you have to say?

Title:

Name:

Email: (never displayed) (will show your gravatar)

Website:

Comment: Allowed tags: blockquote, a, strong, em, p, u, strike, super, sub, code

Please add 1 and 7 and type the answer here: