nuget.exe install not updating packages.config (or .csproj)?

Topics: General
Oct 17, 2012 at 10:22 AM

Also posted on StackOverflow: http://stackoverflow.com/questions/12930868/nuget-exe-install-not-updating-packages-config-or-csproj

While trying to get a nuget build workflow working on Linux/mono, I've noticed an odd thing.

Being on Linux, I cannot use the nuget Visual Studio plugin or the Powershell console, but I have the nuget.exe command-line utility. This utility has an "install" command which properly fetches packages and places them in my packages directory.

However, nuget.exe's install (as opposed to the Visual Studio install) doesn't appear to update packages.config with the packages it added, nor does it add project references to my .csproj. The latter is less important (I can do it manually), since the packages.config needs to contain recursive dependencies as well I can't do it manually...

Has anyone else tried to install new packages solely using nuget.exe or has any insight into this? Looking at the source code the cmdline nuget.exe seems much much less full-featured (and even divergent) compared to the VS. Is this a wanted thing, am I barking up the wrong tree entirely?

Oct 17, 2012 at 3:58 PM

I am seeing this same issue with the latest nuget.exe.

 

Okay, bear with me, I think this is a bug. Let's go through the workflows for updates here.

Here is how you used to do updates in earlier versions of nuget: 

Nuget.exe v 1.6

Install:

C:\temp\dude>nuget install fluentnhibernate -version 1.3.0.717 -x -o package

 

Attempting to resolve dependency 'NHibernate (≥ 3.2.0.4000)'.
Attempting to resolve dependency 'Iesi.Collections (≥ 3.2.0.4000)'.
Successfully installed 'Iesi.Collections 3.2.0.4000'.
Successfully installed 'NHibernate 3.2.0.4000'.
Successfully installed 'FluentNHibernate 1.3.0.717'.

 

Update:

C:\temp\dude>nuget install fluentnhibernate -x  -o package

 

Successfully uninstalled 'FluentNHibernate 1.3.0.717'.
Successfully uninstalled 'NHibernate 3.2.0.4000'.
Successfully uninstalled 'Iesi.Collections 3.2.0.4000'.
Attempting to resolve dependency 'NHibernate (≥ 3.3.1.4000)'.
Attempting to resolve dependency 'Iesi.Collections (≥ 3.2.0.4000)'.
Successfully installed 'Iesi.Collections 3.2.0.4000'.
Successfully installed 'NHibernate 3.3.1.4000'.
Successfully installed 'FluentNHibernate 1.3.0.733'.

 

 

In the latest nuget.exe versions, this no longer works...

Nuget.exe v2.1.0

Install:

C:\temp\dude>nuget install fluentnhibernate -version 1.3.0.717 -x -o package

 

Attempting to resolve dependency 'NHibernate (≥ 3.2.0.4000)'.
Attempting to resolve dependency 'Iesi.Collections (≥ 3.2.0.4000)'.
Successfully installed 'Iesi.Collections 3.2.0.4000'.
Successfully installed 'NHibernate 3.2.0.4000'.
Successfully installed 'FluentNHibernate 1.3.0.717'.

 

Update attempt 1 (old method):

C:\temp\dude>nuget install fluentnhibernate -x -o package

 

Package "fluentnhibernate" is already installed.

 

 

Update attempt 2 (ooh, update works now?):

C:\temp\dude>nuget update -id fluentnhibernate -repositorypath package

 

No packages.config or solution file specified. Use the -self switch to�update NuGet.exe.

 

 

Um WUT?! Let me check documentation here.

C:\temp\dude>nuget help update

 

usage: NuGet update <packages.config|solution>

 

 

I'm sorry, but WHAT?! Why do we suddenly require a packages.config or a solution file to update using Nuget.exe? 

This is a pretty gaping oversight IMO.

Oct 17, 2012 at 4:30 PM

Ethan Brown (Iristyle) just pointed me to this: http://nuget.codeplex.com/workitem/2578

Developer
Oct 17, 2012 at 4:54 PM

@roji, the install is essentially a glorified downloader - it assumes the package is already installed into a project and all it does is lay it down in the file system so that your references would work (which is what we use for the package restore). The update command does edit the project files and updates the config, however it expects the package to be already installed.

Frankly, we don't quite have a workflow to start from scratch and install a package into a project \ solution outside of Visual Studio. The argument for not doing this was that working outside of VS meant we wouldn't be able to work with source control bound VS solutions and run powershell scripts that depended on the DTE (although we don't apply the same argument for the update command). 

Developer
Oct 17, 2012 at 4:55 PM

@ferventcoder, the work item fixes the regression. 

Oct 17, 2012 at 6:41 PM

Woot! Out of band release coming?

Developer
Oct 17, 2012 at 6:49 PM

Yes, we're doing testing now.

Oct 18, 2012 at 9:22 AM

@pranavkm, thanks for answering. Yep, that's the impression I had - no entire workflow support from the commandline.

I can just say that this is the main issue blocking mono usage of nuget, which is a shame... nuget.exe works just fine on latest mono builds (and with the 3.0.0 release happening literally around the corner it will soon be runnable by all mono users...). I've also taken a look at the sources, and it seems a lot of the logic that is there in the VsPackageManager may simply need to be moved to its superclass, PackageManager, thus making the functionality available to the commandline as well. But I'm new to the project and don't know it that well.

Developer
Oct 18, 2012 at 3:51 PM

A lot of the magic that needs to happen already happens in the UpdateCommand (and update is an uninstall followed by an install). I'm pretty sure the code's refactored to a point where it simply needs to be invoked from the install command. 

Oct 18, 2012 at 6:45 PM

Just wanted to add a +1 to this looking do-able.  I know I'd experimented with making a version of Nuget.exe that did just this for my org's conversion over to Nuget.  I ended up writing a one-off app that hit the Nuget Core APIs directly, but it looked do-able to incorporate into Nuget.exe.

One more bit of info -- I've submitted a pull request for a change to the Visual Studio side of Nuget to change the way it writes out HintPaths so that it uses the $(SolutionDir) variable and doesn't break if the project is used from more than one solution.  If my pull request ends up getting incorporated, I assume that nuget.exe would want to function in the same way.

http://nuget.codeplex.com/SourceControl/network/forks/vermeeca/nuget/contribution/3479

If nobody is already actively working on this, I'd be willing to.

Developer
Oct 18, 2012 at 11:54 PM

We have released an update to Nuget.CommandLine package, version 2.1.1, to address this issue. Please update your nuget.exe and verify that it fixes your problem. Thanks for your patience.

Oct 19, 2012 at 2:11 AM

Awesome! Thanks for the quick turnaround.

Oct 19, 2012 at 4:02 AM

However, nuget.exe's install (as opposed to the Visual Studio install) doesn't appear to update packages.config with the packages it added, nor does it add project references to my .csproj. The latter is less important (I can do it manually), since the packages.config needs to contain recursive dependencies as well I can't do it manually...

Thanks

 Advanced seo 2013

Developer
Oct 19, 2012 at 11:59 PM

As pranavkm explained, nugget.exe install does not update packages.config or add project references for you. You need to run the 'install' command, followed by 'update' command to achieve that.