57

Closed

NuGet needs a command to update all packages

description

There is no easy way to update all packages within a solution. Should be a command like Update-Package -All

See Related: http://nuget.codeplex.com/workitem/913 for more details

SPEC: http://nuget.codeplex.com/wikipage?title=Updating%20All%20Packages
Closed Aug 17 at 4:32 PM by JeffHandley

comments

lennybacon wrote Dec 29, 2010 at 10:32 AM

I added the command to the NuGet.exe in my fork: https://hg01.codeplex.com/forks/lennybacon/getcommandfornuget

There are a few issues because in my opinion there are tooooo many requests made by the impl of Nuget core - its slow but works

dfowler wrote Dec 30, 2010 at 3:33 PM

This isn't quite the command we're looking for. We're going to add this command to the core API before any of the clients.

dfowler wrote Dec 30, 2010 at 3:34 PM

Can you be more specific about "too many requests"?

oisin wrote Jan 4, 2011 at 8:57 PM

PowerShell command composition should come into play here:

update all local installed packages

get-package | update-package

update only some packages

get-package proj1, proj2 | update-package

or

get-package | where-object { $_.name -like "Core.*" } | update-package

kvj86210 wrote Feb 7, 2011 at 9:13 PM

The previous post will only update all of the packages for the default project, which isn't what was asked for.

this will update all packages for all projects within a solution.

ForEach ($project in get-project -all)
{
get-package | update-package -Project $project.Name
}

oisin wrote Feb 8, 2011 at 1:38 AM

I'd prefer to see the more succinct:

get-project -all | update-package [-all]

Every time you see a "foreach" in a powershell script in the more common case, someone has usually failed somewhere in the design of the cmdlets.

-Oisin

Haacked wrote Feb 24, 2011 at 12:11 AM

Thanks for the feedback. We probably won't get this in for 1.2 but we'll try to get it in for 1.3. Some considerations we need to think through is whether or not we expose this in the dialog (I would like to somehow without cluttering things). If we do that, what's the UI look like?

jredekop wrote Mar 25, 2011 at 7:03 PM

+1 for this feature. I think the UI could have:

treelist of projects, and the child nodes would be package updates that are available.
Default selected all

rdhatch wrote Mar 25, 2011 at 7:38 PM

+1 +1 +1

techekon wrote Apr 1, 2011 at 7:21 PM

I've found that nuget has created a new DLL hell in regards to solutions with lots of cross project dependencies. If the same nuget package is referenced in several projects if you don't update every single one you still have old versions referenced somewhere it will randomly end up in the bin directory of a project with other project dependencies causing dll a random and confusing dll hell.

This batch file inspired by kvj86210's post updates a single package in all projects of a solution.

$a = $args.length


if($a -ne1)
{ write-warning ("Usage: "+$myinvocation.mycommand.name+" <package-name> ");break }
ForEach ($project in get-project -all)
{
trap [InvalidOperationException]{
echo "No package to update"
    echo ""
continue
}
echo $project.Name
update-package $args[0] -Project $project.Name
}

RobertMcCarter wrote Apr 2, 2011 at 2:01 AM

NuGet is fantastic, but I would certainly love to be able to click on the solution in the solution explorer and say "Update all NuGet packages". Then a dialog box that allows me to pick which packages to update across all projects.

Haacked wrote Apr 27, 2011 at 7:48 PM

Added a spec for the changes we're planning to make to Update-Package to support this: http://nuget.codeplex.com/wikipage?title=Updating%20All%20Packages

sgisbert wrote May 5, 2011 at 12:41 PM

We have developed a local package with Utilities and extensions, that we reuse in multiple projects across one Solution, so definitely when an update comes availiable, which is quite often, we need to update the package in every related projects to avoid the dll Hell... So +1

ferventcoder wrote May 5, 2011 at 2:36 PM

Here is a nuget package that does the update all packages that you can try for now.
http://nuget.org/List/Packages/NuGetPackageUpdater

sgisbert wrote May 5, 2011 at 4:02 PM

@ferventcoder Yes, I saw your suggestion in the related work item 913. It worked like a charm!

Now, looking forward to see it in the Nuget Package Manager extension. Maybe the "Update" button may include a checkbox to decide to update the package in the single project or globally in the solution.

ferventcoder wrote May 5, 2011 at 4:38 PM

I also added a global package uninstaller package... http://nuget.org/List/Packages/NuGetPackageUninstaller

ferventcoder wrote May 5, 2011 at 4:39 PM

Most of the work for that global update was done by the people attributed in the package.

sgisbert wrote May 6, 2011 at 6:32 PM

@ferventcoder, do I need to install NuGetPackageUpdater on every developer machine? or is it installed somehow in the Solution? Thanks

ferventcoder wrote May 6, 2011 at 7:25 PM

@sgisbert: If you are checking in packages, they should get it. They may have to close and reopen visual studio the first time to load the new commands to the console. This only works in the console by the way, not in the GUI.

sgisbert wrote May 6, 2011 at 11:10 PM

@ferventcoder: no, we are trying not to check-in the packages folder, as @davidebbo explained in http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html.

Wondering if adding this package as a dependency of one of our own packages would do the trick, as it would be installed in the next pre-build event... I'll give it a try.

sgisbert wrote May 6, 2011 at 11:28 PM

Tried to add NuGetPackageUpdater as a dependency of our package and it is installed when the package is updated/installed from the UI, but it is not installed when using "nuget install". I guess that's because it's not added to the package.config.

We'll have to tell the developers to install it manually...

sgisbert wrote May 6, 2011 at 11:34 PM

is it a good idea to add manually the dependency a "NuGetPackageUpdater" to packages.config, so that it gets installed with "nuget install"? or shouldn't we edit this file?

sgisbert wrote May 6, 2011 at 11:37 PM

I answer myself: it's not a good idea.

Running NuGetPackageUpdater itself, also updates the packages.config and removes the dependency manually added... :-(

dfowler wrote May 14, 2011 at 8:34 PM

Fixed in changeset d11dab5630ff

dfowler wrote May 15, 2011 at 2:21 AM

Fixed in changeset 848de5e709bf

dfowler wrote May 16, 2011 at 7:47 PM

Fixed in changeset c2a70e4664bd

dfowler wrote May 17, 2011 at 11:25 AM

Fixed in changeset 9ac4ba003c7b

dfowler wrote May 19, 2011 at 9:52 AM

Fixed in changeset 42a682e375ff

dfowler wrote May 19, 2011 at 11:41 AM

Fixed in changeset 1d0f719420af

dotnetchris wrote Aug 11, 2011 at 3:59 PM

Why was this closed?

dotnetchris wrote Aug 11, 2011 at 4:04 PM

Missed this was actually done for not being tagged to a release and all of the black text in a dark gray box

Haacked wrote Aug 11, 2011 at 4:42 PM

Yeah, it's closed because it's done. :)

dotnetchris wrote Aug 11, 2011 at 10:02 PM

@Haacked it would be useful to have this updated to be tied to the 1.4 release of Nuget instead of "Unassigned" which when combined with closed looks like it was rejected not fixed.

Haacked wrote Aug 11, 2011 at 10:48 PM

Ah! It was tied to the 1.4 release, but that release was hidden. I didn't notice because I'm always logged in. Sorry about that. I fixed it. :)

pranavkm wrote May 4, 2012 at 1:28 AM

Fixed in changeset bf73c31c1cc5

pranavkm wrote May 4, 2012 at 1:28 AM

Fixed in changeset 967f8eb2933f

pranavkm wrote May 4, 2012 at 1:28 AM

Fixed in changeset 01fce9d828db

pranavkm wrote May 4, 2012 at 1:28 AM

Fixed in changeset fad3c525612d

feiling wrote Jan 7 at 12:24 AM

Fixed in changeset 4ec72de1bbfb40746915e906bd3ec3da2ae60159

feiling wrote Jan 7 at 12:24 AM

Fixed in changeset 2cc5aff89262f2665f5bf162eb7365f97e25fed1