Install older package version via GUI

Feb 12, 2012 at 9:47 AM

As per this discussion on StackOverflow, it is not possible to install older versions of a package via the GUI. http://stackoverflow.com/questions/5628689/download-old-version-of-package-with-nuget

It would be great to have the functionality available in the Package Manager GUI.

Personally I find the command line not user friendly and I'd need to look-up the exact parameters for the commands to install a specific version.

Keep up the good work, I love using NuGet.

Feb 13, 2012 at 1:55 PM
Edited Feb 13, 2012 at 1:55 PM

Yup, in the spirit of keeping the GUI simple, we decided to only show the latest version of a package ID.

What part of the command line that is not user friendly to you? Perhaps we could improve on it if you can elaborate?

While it is true that you need to look up the parameters for the commands, you'll get used to those after a while. And remember, you can always get help for each command by typing "Get-Help Install-Package", for example.  

Feb 13, 2012 at 2:38 PM

Well, I don't want to make this a GUI vs Command Line discussion, as each has its strengths and followers, and both should therefore be treated equally.

In the package description, where the version is shown, it could be a drop-down list, so you can select a version. I think that still keeps it simple, while allowing users to select versions.

Another possibility is to show the version history as a list, like currently on the website, where you select the preferred version from.

Or, NuGet should introduce stable and unstable channels for packages, so that unstable versions only appear when you opt-in for them.

Thoughts?

Feb 13, 2012 at 2:45 PM

We actually attempted to do the dropdown for versions in the GUI last year, but it was more complicated than we thought because issues kept coming up (though I can't remember those anymore).

Another factor is that the VS control that we use for the GUI has limited capabilities. We can't show anything more than a simple list with customizable item template. 

Regarding stable and unstable (prereleased?) packages, we have implemented in 1.7 build a dropdown that allows you to opt-in to seeing prerelease packages.

Feb 13, 2012 at 2:57 PM

It's a shame that the drop-down didn't work out, maybe you can give it another shot? After all, there's also a drop-down to select the sorting, and that worked out too, hehe. ;-)

One thing I did find out however, is that when you click the package name, it will bring you to a web page where you see the version list. When you click the version you like, the command line example will update with the exact line to execute. That's handy, no need to figure out the exact command via help commands.

Maybe for the time being a link next to the version with 'all versions' or something similar, pointing to that page would do the trick.

Because when you think of it, all I want to do is to select a different version, and the GUI seemingly does not offer a solution for this relatively simple workflow problem.

Great to hear that prerelease packages (beta, alpha and the like I guess?) will be filtered out in the next versions. Those gave me the most annoyances in the past.

Feb 13, 2012 at 4:32 PM

Right now, I don't think I have time to revisit this task. We do accept contribution though. Would you want to give it a try yourself?

You haven't answered my question though. What is it with the PS console that is not user-friendly to you?

Mar 10, 2012 at 5:03 AM

Well, the console is fine, but it just breaks my workflow. I work in the GUI all day, and keying in commands is so old fashioned. I actually need to worry that I type the command correctly! To me, the console is great for scripting, but for daily work I prefer to use a GUI. After all, this is what Windows is all about, right? :-)

Apr 4, 2012 at 1:34 PM

how about a simple check box on the form to "show all versions". When checked it would display a list that has all packages displayed. When unchecked (default) it will show only the latest version of all packages...

Apr 4, 2012 at 5:50 PM
Edited Apr 4, 2012 at 5:50 PM

Believe me, adding the simple check box sounds simple, but it'll require a lot of work. In the end, the effort just isn't worth the benefit. As I said, we have the work around (through the console) and it's good enough for many people. We have more higher priority items on our queue at the moment.

Jun 15, 2012 at 11:33 AM

I too think an option in the GUI to select a previous version is a very desirable feature. We are currently using NuGet packages to manage our internal dependencies between library and projects. In practice, most projects will be selecting a version that is not the latest and thus having our numerous developers remember and type in a command line to achieve this is not ideal. Please can this feature be brought back to the table as I think it would be very useful for many people.

Jun 18, 2012 at 6:08 PM

Then just show all versions and let me pick. No beta or rc versions shown and I have no way to know which ones are even there as the command line does not show that either.

Nov 6, 2012 at 8:28 AM

At work, we also have a need to install specific versions. (and while CLI is perfect for me, others don't like it)

Scenario:

The company has several interal libraries (let call them LibA and LibB, where LibA has a dependency on LibB.
Then there is a ProjectX which consists of multiple VS-projects, some of them using LibA and/or LibB. (Everything of ProjectX is in a single TFS-branch including a single nuget-packages folder. When projects are big enough to have multiple solutions, a nuget.config is used to define the location of the common packages folder).

Now we want to keep only a single version of each library across the whole ProjectX-source/branch (to avoid ambiguous assembly resolutions).
So if somebody needs to create a new VS-project (or add a reference), what he wants is the exact same version of LibA and LibB, which is already in use for ProjectX.

If a specific verion of a package is already used in the current solution, he can add LibA by managing references on solution level and install it in the new project. However since LibA is depends on LibB nuget will fetch a new/other version of LibB (since it wasn't yet in the project). And even then one can end up with multiple versions of the same assembly/package.

If version specific install was possible via GUI, a lot of people would better see/realize that they are introducing possible version conflicts across the project. And they would be able to fix it themselves (if they are too lazy to look up the CLI).

Actually what would also help in this case, is a switch like 'Prefer Downloaded Versions' (which tries to install or fullfill dependencies with already downloaded packages instead of directly looking in the feeds).

Nov 22, 2012 at 4:04 AM

I'm going to take a stab at implementing a version drop-down into the GUI since this is a feature I agree would be very useful. (wish me luck! :)

On a related note I'm going to check for a topic or create one for something that would also be useful. Under Installed Packages it would be nice if we could list not only packages installed in the project, but all packages currently available in the solution. (Either by inspecting all projects in the solution, or the /packages folder. This would help scenarios like abertier mentions where existing projects have older stable versions of dependencies that you want to match for newer projects. NuGet is smart enough to know that the package doesn't need to be downloaded (because it's already in the /packages folder) but you cannot just select the currently available package from the UI.  My thoughts are for the UI that under "Installed Packages" provide two entries. Change the current "All" option to "Current Project" where you go to uninstall packages, add a "Current Solution" which can be used to add references to packages present in all solution projects.

Nov 23, 2012 at 11:51 AM
Edited Nov 23, 2012 at 12:01 PM

Off Topic: This is a short version of my previous post which gave a 'PageNotFound' on submit

Good luck :), but before you give it a go, I want to clarify my opinion again :)


The version dropdown is not sufficient, it only solves the problem of the top level package but not for it's dependencies. And it does not encourage to use the latest versions (although we can argue about this).

 With the release of 2.1 I tried the following config in the root of the source-Branch:

<configuration>
  <config>
    <add key="repositoryPath" value="Packages" />
  </config>
  <packageSources>
    <add key="Used References" value="Packages" />
  </packageSources>
  <activePackageSource>
    <add key="Used References" value="" />
  </activePackageSource>
</configuration>


This approach makes only the used packages available, which is often enough (because we mostly add already used packages to new vs-projects). When adding a new/unused package, you could go to settings and activate one of the other sources. (and be carefull not to autofetch dependencies)

But this has some major issues/bugs:
1) package source should be an absolute path (http://nuget.codeplex.com/workitem/2753). which is unacceptable icm with VCS or multiple devs.
2) when activating an additional source, the relative local scoped packagesource is persisted in the global nuget configuration.

Best summary of the feature I want is: 'Prefer Downloaded Versions' switch/checkbox (as mentioned in my previous post).

I already fetched the sources, but didn't find the time to figure them out and to create a patch. (If it doesn't take too much time I might give it a shot, and let it know, but I don't yet have the big picture of how the sources are structured...)

 

Nov 25, 2012 at 2:27 PM

@stevepi We made a conscious decision to not provide version selectin in the Manage NuGet packages. We want to keep it simple and we know it serves the purpose of most users most of the time. If you want to uninstall old versions, you can use the Package Manager console. So I'd advise you not to proceed with this.

Dec 28, 2012 at 12:03 PM

The ability to see older versions in the PM GUI would be a great feature.  I agree with some of the other posts here that some users just dont like to remember how to use command line interfaces.  A GUI is much easier for them to remember on the fly.  If the original request here could be revisited at some time that would be great :)

Dec 28, 2012 at 3:40 PM

The command line to install package is just so easy to remember:

Install-Package jQuery -Version 1.2

I'm not sure why any developer can have trouble memorizing this command.

 

Dec 28, 2012 at 4:56 PM

You and I can deal with it; many others don't use command line tools at all.  They are all about using GUI's.  Just like I know I can invoke the C# command line compiler via csc.exe or run msbuild against my .csproj others choose to use the build menu in Visual studio.  Just saying it would be a cool feature to keep the GUI in sync with the PM Console

Dec 28, 2012 at 6:41 PM

It is not our goal to keep the GUI in sync with the PM console. We want to keep the GUI simple while still meeting 95% of the main use cases. For more advanced scenarios, developers are required to use the PM console.

Sure we can add option to allow installing older versions in the GUI, but that would clutter the UI and require non-trivial amount of work. In the end, we don't feel it has enough bang for the bucks.

May 13, 2013 at 4:09 PM
Bit belated, but I'd like to throw my vote in for allowing version selection via GUI. I've run into the situation where the latest versions of all the enterprise library packages are up but they target only .NET 4.5 which is not what I'm developing for. At this point, I can't use the GUI at all since it won't install the packages on anything other than .NET 4.5 targeted projects. So, to install all of the various packages I need, I need to go look up the last version that works with .NET 4.0, take note, install via command line, then repeat for the 8+ other packages. While this process not hard to do, it is rather inconvenient and repetitive. So, if version selection isn't on the plate, how about filtering the latest version available to the last available for the project's selected framework?