Changing ID for Package that Depends on MVC version - best practice

Topics: Ecosystem, General
Jun 24, 2013 at 3:21 PM
Ok, so I noticed the discussion Changing package id - best practise , but it didn't help much in my situation.

We have packaged up a new version of [MvcSiteMapProvider] ( with support for MVC2, MVC3, and MVC4 in addition to .NET 3.5, .NET 4.0 and .NET 4.5.

Based on [this post] (, I came to the conclusion that I need to create a separate package for each MVC version. That sucks because we also have packages that depend on the main library, so instead of the desired 13 Nuget packages, we ended up with 37.

First of all, is that post correct/current in that there is no support for multiple MVC versions in Nuget like there is for .NET framework version?

While we did figure out a way to make 37 packages maintainable, how are we supposed to map a package with a single ID to 3 MVC version packages (and more to come when MVC5 is released) as in the solution suggested by the first discussion I linked to above?

Previously: MvcSiteMapProvider
Currently: MvcSiteMapProvider.MVC2, MvcSiteMapProvider.MVC3, and MvcSiteMapProvider.MVC4

Finally, our original package has some 42,500 downloads. It seems a bit unfair to have to reset to zero because of a Nuget packaging issue that couldn't have been foreseen. Is there a way to move our previous popularity points to our new package if nothing else?