NuGet.exe requires INSTALL, UPDATE, INSTALL to get new version?

Aug 10, 2011 at 1:13 AM
Edited Aug 10, 2011 at 1:14 AM

Just want to query the usage pattern around the UPDATE process.  The workflow we want is to allow developers to update the binaries quickly from an empty packages directory, as we are not committing the packages to SCCM.

It appears that the current pattern requires the following:

  1. INSTALL to get the packages folder populated
    1. Reads packages.config
    2. Goes and gets the packages
    3. Installs to packages directory
  2. UPDATE to query and check for later packages
    1. DOES NOT read packages.config for the current packages that would be installed
    2. Iterates over packages installed in the packages directory
    3. Queries for updated package versions
    4. Updates packages.config
  3. INSTALL again to get the new versions based on the updated packages.config

Question is: why cant an UPDATE occur based on the content of the packages.config file alone, rather than an enforced INSTALL based on the packages.config file first?  Seems counter intuitive, and requires a round trip duplicate install of binaries when generally we will know there is an updated set that we want.

Aug 10, 2011 at 1:18 AM

One reason for this is that we need the old package around in order to correctly uninstall the old version before installing the new one. e.g. the old may contain some assemblies which don't exist in the new and should be removed, and we can't know this if the old is not around.

However, in practice there are certainly many cases where it could work without the old one present, but that is the reason why it works the way it does :) 

Aug 10, 2011 at 1:19 AM

Update does read packages config if you pass that to the command.

Right now nuget.exe update as it is today is a half baked feature and that's why it's counter intuitive. It will get better when we figure out a proper workflow. NuGet wasn't designed for this type of usage, but it's evolving quickly and will cover more scenarios like these as time passes. 

Aug 10, 2011 at 1:22 AM

Ah, I actually missed the fact that you were trying to update using nuget.exe and not from VS. So yes, what he says...

Aug 10, 2011 at 1:31 AM

@dfowler I agree, it does appear to read the packages.config, but I think it only does that to establish the project file associated with it, rather than use its contents to establish what package checks should be done.  Agreed re NuGet quickly evolving, are you happy for us to help out with workflow/fixes?  For a large corporate, and the type of dependency graphs and project counts we are dealing with, these type of features are a requirement to get NuGet working the way we need it to.  VS integration is almost secondary to the CI usage.

Aug 10, 2011 at 1:45 AM

That's actually incorrect, as the packages.config is the main source of truth. The project file has no relevant information about packages.

I'd love to hear what the ideal experience would be for you workflow.

Aug 10, 2011 at 4:03 AM

@dfowler Sure, it is the source of truth, but it doesn't appear to get used as such during the command line update process unless the packages folder is populated, for the reasons that @davidebbo stated I guess.

Happy to break down our ideal workflow.  Started on another discussion here:

I think the main issue is that the dependency graph for our solutions/projects (and for many corporates I have worked at) is much larger than that in many standard open source projects, and generally contains many more in-house library dependencies.  There is also strong governance around when a library gets built, and with what code changes, so the manual update of package references is problematic as it is a step that our existing solution does not require.  Will have a think of the best way to describe these requirements and workflows.