Adding an option to choose the version number to the NuGet Manager window in Visual Studio

Topics: General
Aug 14, 2013 at 3:03 PM
When you add a NuGet package to a project, you always get the latest version of the package. When you have a big solutions with several projects using different NuGet packages, it is sometimes required to install a specific version of a package, so you won't get reference conflicts.
Since this happens often, instead of forcing developers to work with the package manager command line window, why not add a drop down to the manager window that shows the list of existing versions for the package. The developer would then be able to select from either installing the current (latest) version or a specific version.
Aug 14, 2013 at 6:07 PM
While this is a good suggestion, we do want to keep the design of the Manage Packages dialog simple. Adding more UI controls to it can increase the complexity of the UI and affect performance (because we have to load all versions of every package).

Why are you not so keen on using the Powershell window?
Aug 14, 2013 at 6:19 PM
The window already contains a combo for "stable/pre-release" options. Maybe you can add a third option "stable historical" which will turn on this feature.
The feature itself can be by replacing the "install" button with a combo button with the default option of "Install latest" and "Install vX.X.X" for each existing version.

As for why i'm not so keen on using the powershell window, i'm an MCT and my experience with developers show that many of them don't like to use command line tools, as it is perceived by them as an "advanced" feature. Since this is not an advanced feature (select a nuget version that is), I would like to have that feature more available to them.
Aug 15, 2013 at 5:47 PM
I do think we'll start offering version selection in the dialog. I've been having some conversations with various folks about a "version branch" concept too, where if there are minor-version updates as well as major-version updates to packages you have, you'd get the minor-version updates by default and it would require explicit action to jump to a new major version. The version branches would default to Semantic Version major versions, but a package author could (at the time of publishing, or after) mark a minor version as a new version branch.

Take the jQuery 1.9 scenario for instance, where it was truly a major version, despite not being 2.0. jQuery 1.9 could have been marked as a new version branch and users on 1.7 would see updates to 1.8.x by default, but they'd have to opt into 1.9.
Aug 20, 2013 at 9:17 AM
That's great news Jeff. Is there a schedule for this? or a work item I can track to see when this feature is added?

Thanks,
Ido.
Aug 20, 2013 at 3:45 PM
Just an FYI that I second this feature.

We're currently designing how we'll manage versions of our internal, shared libraries, and it was identified that if we have multiple project/dev-level branches, each aimed at features of the common library for dev-level, or upcoming, features of multiple consuming applications, there was no way through prerelease versioning to make more than one project/dev-level package available.

This feature would allow us to use standardized names for the prerelease version so you could easily tell which dev-level branch you were pulling from the UI. Without it, you would only see the highest alpha-sorted prerelease version.

I have a hard time getting my devs to step outside Perforce's P4V and the Visual Studio Perforce Plug-in, so I know using the Management Console would be a challenge, requiring us to spend additional time to train them.

Thank you for adding this and I can't wait to see it implemented!
Aug 21, 2013 at 4:49 PM
Nothing yet - just early thinking. I'll get something filed though. It'll be a couple versions at least before that feature would materialize.
Feb 6, 2014 at 8:31 PM
I would also be very interested in the ability to select a previous version of a package when choosing to install it. This would be very helpful.