As you know NuGet uses %LOCALAPPDATA%\NuGet\Cache location for caching. It first checks if requested packages is here then download if needed.
How can I properly disable this cache mechanism from Nuget and "Visual Studio 2013", and make sure they always download from sources?
Can I build Nuget Package Manager Extension from source, then install it to Visual Studio? Or Are there any registry configuration that disable it?
Thanks
You cannot disable NuGet from using a cache. The only thing you can do without changing the source code is to change the location of the cache directory using a NuGetCachePath environment variable.
So you are left with clearing the local cache manually or automatically before installing a NuGet package or modifying the source code for NuGet's Visual Studio extension.
The source code for NuGet 2.8.5 and older is available on CodePlex.
The source code for NuGet 3.0 is available on GitHub
There are some instructions available on how to setup the NuGet development environment to be able to build and run NuGet within Visual Studio.
Currently it's possible to do so in case you'd running Install NuGet packages task through CLI which is common practice.
You can order NuGet to not use it's cache at all by using -NoCache input parameter. Then it will behave as you described. See CLI reference of NuGet.exe
Related
Let's say I have a nuget package in my Nexus repository called MyPackage.1.0.0. I also have a solution in Visual Studio that has MyPackage.1.0.0 installed. If I make a change to my nuget package in Nexus but I don't change the version number, what happens in Visual Studio? Will Visual Studio know that the installed package is outdated? Will it automatically download the new version next time the solution is built?
No, Visual Studio will not detect this and will not use the updated package. Also, if you are using package reference nuget package management format, the package once installed gets extracted to the global packages folder. If you now try to install this package in a completely different project, nuget first looks in this global packages folder and if it finds it which it will, it will use it and not go to package sources to retrieve it again.
You can clear the local nuget caches by calling
nuget locals all -clear
from the command line.
After that, all packages will be downloaded again. This may be acceptable during development (i.e. if you need to tweak your package until it works), but clearly is not an option if others are using the same version already.
Does NuGet support global package installation like NPM and Composer? If so, how do I do that? Also, how do I reference globally installed packages in my Visual Studio projects?
So learning from #Lance's tips, I went ahead and checked %userprofile%\.nuget\packages folder, and indeed it contains all the packages that I have downloaded in the past. Unfortunately though, Visual Studio (I'm using Community 2019) does not allow you to install any of these packages into a new project. The Browse page in NuGet Package Manager UI displays online results only from nuget.org.
But then I found another clue. In Visual Studio Tools > Options > NuGet Package Manager > Package Sources, you can add custom sources. So I went ahead and added my cache folder as an alternate source.
Note that there is a separate "Machine-wide package sources" entry too that cannot be modified. I checked that folder and it contains mostly Microsoft's own packages (one exception that I found there was NewtonSoft.json). I have no idea how this folder is different from the nuget cache folder and how I can download a package to this folder.
So far so good. The Package Manager now shows all previously downloaded packages from cache when I select this source from the drop down (sources dropdown is in top-right corner). I can then select a package and install it from local source instead of downloading it from the Internet.
Hope this helps someone down the line.
I know there's an answer for this question from 2016 but it's not working today. I have VS2013 with the latest CU installed.
My Nuget package source settings:
I want to install the nu-get package "Serilog.Sinks.MSSqlServer". First, I ensure nuget is up to date by navigating to the ".nuget" folder of the solution's folder and running "nuget update -self":
Unfortunately, I still get the error when trying to add the package:
If I try to update nuget from the "Extensions and Updates" page of VS then I get a 403 error as shown below:
The 403 does suggest a proxy issue but other packages can be installed to the same dev box ok. I just installed "Apache log4net" from the Manage NuGet Packages window - no problem
Any ideas of a work-around for this please?
This might be related to the fact that you now (with the new NuGet CLI tool version) need to use the new NuGet API.
from nuget.org
NuGet feed v3 (VS 2015 and later / NuGet v3.x and above): https://api.nuget.org/v3/index.json
NuGet feed v2 (VS 2013 and earlier / NuGet 2.x): https://www.nuget.org/api/v2
You can check (and edit) your NuGet Package Sources under Tools, Options, NuGet Package Manager, Package Sources.
#Rob Bowman, in response to your comment and looking at the screenshot of your Available package sources, try edit your default nuget.org to https://api.nuget.org/v3/index.json or add a new source and make sure they're both enabled. Maybe that'll do the trick.
Update: maybe manually updating the NuGet Package Manager (since updating it through Extensions and Updates is not working) solves the problem. NuGet Package Manager for Visual Studio 2013.
Going to Visual Studio menu Help, About should display the currently installed version of this extension (and others).
To fix this I had to:
logon to a PC not connected to the corporate proxy
download the latest version of the nuget package manager (VSIX) for VS2013 from https://marketplace.visualstudio.com/items?itemName=NuGetTeam.NuGetPackageManagerforVisualStudio2013
copy the VSIX to my corporate dev VM and install
We recently added a few dependencies to our project using NuGet. To keep the binaries out of the version control system, I enabled the package restore feature and added the resulting .nuget folder to the repository. Also the project with the dependencies got the RestorePackages option set to true, and an Import-tag for the nuget.targets within the .nuget folder.
So that all works well on my machine with NuGet installed and the package restore feature enabled in my VS settings. However when I want to use this setup to install the dependencies on other machines I run into a few problems.
I was under the impression that one advantage of including the nuget.exe would allow me to use this on machines that do not necessarily have NuGet installed. However, after reading the article on consent I think the reason it actually fails is that those machines do not have the package restore feature enabled in their settings – obviously as they technically do not even know about NuGet.
What is the preferred way to enable package restore on machines that do not have NuGet installed? Is not having NuGet installed actually a valid option other than for build servers?
Or ideally, is there a way to enable package restore by default from the solution if NuGet isn’t installed itself and as such the setting could not be set by the user? (I actually could think of a setup-script that creates a NuGet.Config to %AppData&\NuGet)
Try this:
Install-Package NuGetEnablePackageRestore
Or check the contents of the package (unzip it), you'll find some interesting stuff there that will help you out (e.g. there's a way to set an environment variable from within MSBuild). You can download the package within the browser after logging into NuGet.
"Or ideally, is there a way to enable package restore by default from the solution if NuGet isn’t installed itself and as such the setting could not be set by the user?"
The alternative to install NuGet and enabling consent through the Settings is to set the following environment variable :
set EnableNuGetPackageRestore=true
If EnableNuGetPackageRestore (mentioned by Alexandre Dion) variable used as emmited Property for Msbuild script (I strongly suspect it work this way, but cant check right now) - you can tune up your projects or sln to set this additional property to true.
Anyway, according to this you should have at least nuget.exe as console manager for each dev. Otherwise you cant fetch referenced nuget packages.
I've added some libraries to a VS 2010 solution using Nuget (RestSharp, Twilio, etc.). When I pull the same solution down to a new PC from TFS and try to build it, all the references to those assemblies are broken (error "namespace cannot be found..."). Is it necessary for each developer who works on this VS solution for the first time to independently install the same Nuget packages on their PCs?
Thanks,
Jim
As Andrew already have said it's all about the packages' location.
Either you have to check in the entire packages folder with all the packages, or each developer have to install the packages after first checking out. But there is a better way to do this, namely to use NuGet Package Restore - which will automatically install all missing packages when the project is built.
If you use package restore, you only need to check in the repositories.config into your VCS. With TFS you can cloak the entire packages folder except for the repositories.config, so that TFS doesn't annoy with pending checkins for new packages.
Also see this answer for guidance on how to use TFS + NuGet.
No, but you need to be sure the assemblies are all included in the same relative path so Visual Studio can find them. You can include the solution's nuget packages directories, which is where I think it stores a copy of the libraries to be referenced by the project(s).
Incidentally, including said diretories may be effectively the same as "installing the packages". If you include all the files that NuGet uses in its management of packages, NuGet will behave the same as if you had installed them. But you don't need to do the actual package install via NuGet for it to work... or even have NuGet installed in Visual Studio in the first place. It's just a matter of the proper files being where the Visual Studio project files expect them to be.