NuGet Local Cache

Topics: Ecosystem, General
Oct 1, 2013 at 6:26 PM
Edited Oct 1, 2013 at 11:22 PM
Hi Folks,

One of our highly voted work item is As we are looking into this issue, we would like input from you folks for the following. Please chime in your thoughts. We would like to make sure we addressing the right pain points.

Why do NuGet users want to be able to install packages more aggressively from the cache?
  • Is it because users need a smoother offline experience?
  • Or is it because users know what they want is in their cache and they just want to use it?
-NuGet Team
Oct 2, 2013 at 7:30 AM
I would vote the first.
Oct 2, 2013 at 7:50 AM
Most users don't realize there's a cache. I'd vote for the first: smoother offline experience.
Oct 2, 2013 at 8:19 AM
+1 on the first. Smoother offline experience. Both on developer clients and on build servers. That said IMHO it would also be useful if it was dead simple to clean the cache.
Oct 2, 2013 at 2:36 PM
There are a couple of issues with bad connectivity (3G MiFi on a train):
  • Name resolution (Nuget will cache errors, especially for a proxy I forgot to turn off from the office)
  • Timeouts (Nuget will cache errors)
To fix both of these I need to restart Visual Studio to get Nuget to retry. An option to (or some automatic) retry would help a lot here.

I have a package source setup to point to my local cache, and maybe this should be configured as such by default.
Oct 2, 2013 at 3:40 PM
It is definitely the first one.

But please keep in mind that there are people with multiple feeds. When one feed goes offline I don't want to end up installing packages from the other feed because they are accidentally in the cache.
Oct 2, 2013 at 8:19 PM
I'd say the first one.
Oct 2, 2013 at 8:20 PM
For me it's for the offline experience.

On a related note, the package manager should not fail if some of the package sources are unreachable. I often have to jump into settings to uncheck a source that I know I can't reach at the moment (corporate repository when not on VPN, for example).
Oct 2, 2013 at 8:25 PM
It's for the offline experience. Every time I do a demo at a conference I need to create a local repository.
Oct 2, 2013 at 8:28 PM
I would suggest to everyone that they look at how various Linux distributions handle the concept of package management and distribution -- and what problems they solve. Although what is in the package differs between a given Linux distribution and NuGet, the concept and problem domain are the same.

The entire NuGet Gallery should be easily mirror-able. NuGet should function the same regardless of which protocol is used to transfer the package (file vs http). A configuration file with priority of all the various sources should be exposed so that if there is a conflict of package version; the source with the highest priority wins.
Oct 2, 2013 at 8:31 PM
Definitely the first. As ssuing8825 said, I'd want it mostly for conferences and user group presentations, and when my VPN is down.
Oct 2, 2013 at 8:34 PM
+1 on the first, and problaby the most common nuget packages ( entity framework, webapi, mvc, jquery, )...
Oct 2, 2013 at 8:36 PM
+1 on the first for me as well. I could see value in the second as a bonus BUT the times I needed it and it wasn't there is by far the winner in my case.
Oct 2, 2013 at 8:49 PM
howarddierking wrote:
@FilipDeVos - one question on package source. If a NuGet package is immutable and versioned, why does it matter where you source it from?
Who says it's the same package? Could have been recompiled locally with the same id (for compatibility) as per an enterprise repo. I'd say you need to compare hashes of the packages to ensure it's actually the same.
Oct 2, 2013 at 9:18 PM
+1 on #2 for me.

My pain point is this:

I have a solution with 12+ projects in it, all referencing version of a NuGet package. Now I add a 13th project and need to add a reference to the same package in the new project. If I go online and install, it may install version of the package which will create references to different versions within my solution (not a good thing).

Yes, I could specify version of the package using the command line and/or console, but that assumes I know what version I am using in my other projects.

So I usually go to my solution, right click for the package manager, find the nuget package and add it to my new project. This guarantees all are using the same version.

If there was an easier way to do this, then that would be good. For example, on the "Install" dialog, if there was a selection based on the local cache, I could just choose it and go.
Oct 2, 2013 at 9:44 PM
+1 for #1
Oct 2, 2013 at 10:12 PM
if you are talking about a caching like node.js package management (npm install -g command) I think that will do the trick. I sometimes want to install the package and use it for lots of projects. I think globally installed packages might also win.
Oct 2, 2013 at 11:29 PM
+1 for #1. The build server doesn't know what's in the cache (and shouldn't)
Oct 2, 2013 at 11:45 PM
Oct 3, 2013 at 6:26 PM
+1 #2. I've installed the package before on another project. Who cares if I'm on-line or off? Go and get it from cache.
Feature request: Option auto-update of installed packages.
Feature request: XCopy deploy. I can "install a node package" with an xcopy from another project package directory.
Oct 5, 2013 at 10:01 PM
@howarddierking The package Id and version are unique and immutable on one nuget feed.

A developers pushes package "Test 1.0.0" to one feed, and another developer pushes "Test 1.0.0" to another feed. As long as the source is not included in the cache, things will be a mess forever.

Since virtually nothing is strong named on and package content is not validated we re-host the dependencies we use with the same version number and strong named assemblies.

I mentioned this in my "things to fix" thread from a while ago already.
Oct 5, 2013 at 10:03 PM
@howarddierking Also, packages are only really immutable on If I use c:\packages as a feed I can do whatever I want with the packages.
Oct 8, 2013 at 8:16 PM
howarddierking wrote:
FilipDeVos wrote:
@howarddierking Also, packages are only really immutable on If I use c:\packages as a feed I can do whatever I want with the packages.
That makes sense - so would having the cache track the source for a package as well (similar to a browser cache) address this issue?
Indeed, in my opinion the source should be part of the package identity.
Oct 8, 2013 at 9:28 PM
howarddierking wrote:
I'm having a hard time with this one. If we need to compare hashes in order to determine whether 2 packages which have the same version number are actually the same version, what was the point of having a version number in the first place? I understand that NuGet enables this sort of thing (e.g. same package version for different actual package versions) - but I'm having a hard time seeing it as a good thing that we should effectively make it a mainline, supported scenario by having a hash as a "secondary version".
I think package identity should be name, version and source. And since packages are not immutable, there should also be a package hash. We can look at something familiar as an example; Assembly names:

At install time the signature would be pretty much transparent for the user unless there is a conflict between the package in the packages.config and the package being fetched by package restore.

I understand this is hard to get right when there is a cache in play, but I do think it is worth getting right.