I fell victim to overly aggressive caching twice today while working with UWP projects.
I was attempting to upgrade packages using the NuGet UI in VS 2015. NuGet clearly showed a new version of the package; it successfully installed into all my projects EXCEPT the UWP project. This is what it showed:
You can clearly see that the NuGet UI is offering version 110, but NuGet refuses to install it into the UWP package because its cached data says it doesn't exist.
The second time I hit this was during package restore on a CI machine. All packages restored for non-UWP projects including the same versions of other packages; however, the UWP project refused to restore the package which was there (presumably again because of cache, though the NuGet 3.1 beta command line utility was not nearly as forthcoming as the VS UI was):
Unable to find version '2.1.0-beta4-build3106' of package 'xunit.runner.utility'
I logged into the CI machine and tried to run the solution-level restore by hand, using the -nocache flag, but even that wouldn't restore (it seems like the UWP restore ignores that flag). I had to manually install the package into the packages folder with a simple nuget install, which of course succeeded immediately; once the package was then in the local machine cache, the CI builds were allowed to succeed.
Whatever package caching mechanism is in play is clearly: (a) too aggressive, (b) not in line with other NuGet restoration policies (the fact that UI finds the package and then refuses to download it and install it is mind boggling), (c) unable to be overridden by any mechanism.
This was an amazingly poor user experience.
Please try this, this is long procedure, but once setup, it ignores NuGet caching https://github.com/neurospeech/NuGetProxy
@neurospeech this is creating extra load on the server that is already overloaded, and does not resolve the issue (because caching happens before you even go out to the wire in this case).
Please be careful with sharing it.
@bradwilson this is the caching code from DNX, we do need to improve it. You can delete the cache manually (yes I know it sucks) and we do need to improve it as soon as possible
CC @davidfowl @damianedwards
@yishaigalatzer this is not creating extra load, in fact all it does is routes query to new version which is used in UI, package is already available on UI and on website. Problem is NuGet is breaking build, one developer adds new package and is not available to other developers. Either package should not be available on UI or if it is available, it should be available everywhere.
What happens with this proxy is that it routes from methods that hit the lucene index to methods that hit the already overburdened database. Which is a solution to when the lucene index is in bad state (and we have just deployed a major fix)/
The issue described here has to do with local caching for v3 queries that 1. Don't go through the odata server at all and hence rewrite wont help. 2. Are cached aggressively on the user machine and hence wouldn't hit the proxy.
We have a design for this. I will post it later today in our new wiki section
I've fixed this for the 3.2.0 release. Installs and updates will only use cached entries newer than the start time of the package operation. If an older entry is cached from before the package was uploaded it will be cleared out.
Excellent, thanks everyone!
Verified that the behavior is as desired. For Install-Package and Update-Package from powershell console, the cache is busted. Whereas with restore, we use the cache