local cache update methodology

Topics: General
Jul 6, 2012 at 8:06 PM

Am I correct in assuming that the local package cache is updated only by checking the package name and the version number?

We are prototyping converting our VS projects to use nuget.  Our concept was to create nuget packages for each of our builds, but use the same build number for each package consecutively built in a code line.  This would allow us to get the latest build without having to manipulate the packages.config and the csproj files every time we wanted an updated lib.

This methodology assumes that the local cache will always check to see that it has the latest build (for a given package name with the same build number).  Our recent tests seem to show that the local cache is not getting updated for new builds of the same package name/version combo.

Is it possible to either disable the local cache, or (more preferably) have the cache checked against the repository based on chksum or some other differentiator?

Jul 6, 2012 at 9:17 PM

If you're specifically talking about package restore (viz Nuget.exe install), we treat the local cache as a first class repository and install the package from it regardless of what it is on the server. You could prevent us using the cache in this manner by using the -NoCache flag. 

For everything else, we will invalidate the local cache if it is not identical to the server's copy. 

Jul 13, 2012 at 4:02 PM

So using nuget update will automatically update the local cache?

i.e. alter NuGet.targets:

<RestoreCommand>$(NuGetCommand) update "$(PackagesConfig)" -RepositoryPath "$(PackagesDir)" -source $(PackageSources)</RestoreCommand>


Jul 13, 2012 at 4:13 PM

Yes, if we have to hit a http based repository, we will drop the new file in there for you. That said, given that it's a cache, we do clear files from it using LRU - so its very predictable. 

Jul 13, 2012 at 8:00 PM

Unfortunately, testing seems to show that this isn't the case.  The only way I am able to download a newer package with the same name and version number is to delete both the local cache and the packages directory.  The update command has no bearing on this.  Having to delete the local cache and the packages dir in order to pick up the latest version of internally generated libs, continually built is not very practical.  Developers will forget to update their libs, and their builds will fail unexpectedly.

Also of note is that the update command cannot be used alone, as it relies on the packages dir to pre-exist. 

(Testing was done with nuget.exe 2.0.30619.9000)


So, in an enterprise CI scenario, we have to update the package number for every build.  Someone will have to update all the downstream packages.config files and the HintPaths in the csproj files for every project.

(The build server could update these files and check them in for every build, but I've never been a big fan of build servers checking in code)


How is this supposed to work when you continuously build dozens of solutions and hundreds of projects?


PS Using TeamCity here, any ideas or real-life solutions using that would be greatly appreciated