I see that the folder %HOMEPATH%\.nuget\packages has many nuget package downloads.
What's this folder for? Is it so that every time I download any NuGet package on my machine using the PowerShell or the NuGet Package Manager in Visual Studio, the package is first cached in this location? That seems like the only plausible answer but I'd like to confirm.
When do packages get added to this folder and who adds them?
It is just the nuget cache, so it does not have to download the same packages over and over again.
It is managed by Nuget itself. If you find it gets too big (and it does), there is nothing wrong with deleting it.
Related
Under c:\Users\<USER NAME>\.nuget\packages\ directory, there are some folders looks similar, for example:
System.IO.FileSystem.4.3.0
system.io.filesystem (and there are sub-folder "4.3.0" under it)
See attached figure.
My question: why are there similar Nuget package folders in .nuget\Packages directory? Can I delete one of them?
Possibly you used an old version of NuGet or Visual Studio on your machine, which used the old format. The other option is that you have a nuget.config that forces that solution packages folder to be your user profile's global packages folder. I really don't recommend this.
Maybe starting with NuGet 3.0 (Visual Studio 2015), NuGet uses the tolower(packageid)\tolower(packageversion)\ folder structure. I'm too lazy to test old versions to validate that earlier versions used something different. Or maybe NuGet has always used the same format for the global packages folder, making the packages.config answer the only possibility. But I really think that lowercase normalisation was something that was added and didn't always exist.
projects that use packages.config have always used the unmodified PackageId.PackageVersion format in the solution packages folder. I believe it was deemed too risky as a breaking change that some customers depend on to change in the solution packages folder. So, if anyone had the misguided idea that they could save disk space by making all their solutions share the same packages folder by using the same one for all solutions, and the folder they used is the global packages folder, then the two different parts of NuGet which intentially use different folder naming conventions, will write to the same directory.
As long as you're not in the middle of a build, it's always safe to delete folders in any packages folder (global packages, as your question is about, or a solution packages folder). If a project needs a package that was deleted, NuGet will download it again, so if you have a download quota, or a slow internet connection, maybe be mindful. Otherwise you can be as liberal with deleting folders as you like. Just make sure to delete the entire folder. There's only one file NuGet looks for when restoring, so if you delete other files but leave that one, NuGet will think it's downloaded and extracted properly, but your machine will behave differently to other machines.
In the project I've been using some custom NuGet sources. Apparently some of them are no longer available but I do have the newer (and only newer) versions of the packages on the other (still working) server. Is there a way to restore the packages directly to the newest versions without manually replacing all the references in the .csproj and packages.config files?
I've tried running Updade-Package -Reinstall but I only get the following error message:
Some NuGet packages are missing from the solution. The packages need to be restored in order to build the dependency graph. Restore the packages before performing any operations.
If some packages you use (and still want to use) are no longer available, I suggest you to make a backup of them.
Find the Nuget cache on your server. On Windows this is located at
%userprofile%.nuget\packages
Spot the packages (and version) you want to backup and copy the .nupkg files in their respective folders.
Then you have two choices:
Create a private Nuget feed
Create a local Nuget feed on your development machine
The 1st option has the advantage to be a single source that can be used on any machine you want (development machine, build server...etc) but you will have more set-up, especially for the authentication/authorization (because it's a private feed)
For the 2nd option: Simply create a C:/Nuget folder and put any .nupkg you want.
Then in Visual Studio go to:
Tools -> Nuget Package Manager -> Package Manager Settings -> Package Sources
Click on the green + button to add a new source, simply give it the name Local and browse to your C:/Nuget to set the source.
From now on when you want to restore your Nuget packages, Visual Studio will first look into the nuget.org feed and if it doesn't find the referenced packages, will then look into your Local feed and cache the installed package to the %userprofile%.nuget\packages of your machine.
I hope that answer to your question, I was not quite sure about what you asked and your knowledge about Nuget.
UPDATE:
I think I understand your question better now.
First of all, I think your misunderstand the Update-Package -Reinstall command. It will reinstall the packages with the SAME version as already referenced but simply reinstalling them. It's a useful command for example when you change the target framework of your project. Then you can reinstall the same versions of the packages and they will retarget this .NET Framework version.
So if a nuget restore isn't working then Update-Package -Reinstall will obviously fail too.
With Nuget, when something isn't working, you shouldn't insist but instead, find the tweak that will make it working again. I can't count how many times I went to the different caches to delete some cached packages.
I think you should try to use nuget restore and see what packages are causing issues, then uninstall these packages (this will just remove the reference from the .csproj and packages.config if they aren't installed in the project yet), then you can finally install the newest version of these packages.
My CruiseControl.NET build server is not able to restore the nuget packages of my projects. According to some websites it should be enough to set the environment variable EnableNuGetPackageRestore to "true" and restarted Cruise Control after that, but that didn't help in my case.
What else can I do?
Do i need to install something that "enables" Nuget?
I noticed I have a .nuget folder in C:\Users\MyUser\ but I don't have this folder on the build server. Is this required? Who created that on my pc? Visual Studio?
Without seeing the project config, I am assuming you are using either a Microsoft Solution or project, and are building from that using the msbuild task in CC.net. If so, your Solution needs a .nuget folder structure (in the same location as the sln/prj file there needs to be a .nuget folder, inside that folder, you need a NuGet.Config and a NuGet.exe as well as a NuGet.targets).
This should be automatically added to your solution if you right click on it inside visual studio and select "Enable nuget Package Restore".
You can find more information # Nuget Documentation. There is quite a few ways to skin this cat, but, based on your initial statement, you are just missing the .nuget folder in your Solution, and once added it should just work. Otherwise, you have to look at pre-build tasks, and that gets a little more detailed than is usually necessary.
I recently migrated all my Visual Studio 2013 projects to Visual Studio 2015 and followed the steps documented in this article by Nuget to make sure that automatic package restore is still working, in short
I deleted the Nuget.exe and Nuget.target files from source control and disk
I updated all project files and deleted the sections related to Nuget
I'm experiencing a problem when I'm updating Nuget packages, it is not updating the project references to point to the newest dll versions. I can see that the newest packages was installed though. This problem is also not related to specific packages.
Has anyone else experienced a problem like this?
NuGet package restore does not modify the project files. It just downloads and extracts the NuGet packages to the packages directory.
If you are trying to edit the packages.config file and then have the project's updated you would have to use the Package Manager Console and run:
Update-Package -reinstall
Which will uninstall and install the packages again and update the project's references.
We realized that some of our junior developers only installed the required Nuget packages for ONE project in the solution, they then added references to the required dll's for all other projects by browsing to the physical location of the dll's on disk. This obviously caused the problem because only ONE of the projects in the solution contained entries for Nuget packages in it's packages.config file while the remaining projects in the solution contained none.
When all packages were updated using the Update-Package command only the ONE project containing entries in it's packages.config file were updated with the correct project references.
Even though this is not a Nuget bug and rather a problem caused by inexperience, I logged an issue with Nuget to see if they can improve the software to prevent these types of problems.
So I recently had a very similar issue as well, unfortunately uninstalling and reinstalling did not work. Hopefully this helps anyone else as it was very frustrating.
Steps:
go to or launch the quick launch feature.
type package manager
select "tools->Nuget PackageManager-> Package Manager Settings"
In the options window that pops up. click "Clear All Nuget Cache(s)"
Right click solution and select Restore Nuget Packages.
Hope this helps.
I was facing an issue with NuGet package of Newtonsoft.Json as shown below:
I tried all possible solutions but none of the below mentioned ones worked:
Cleaning solution
Rebuilding solution
Clearing NuGet package cache
Finally I realized it had something to do with .NET Framework version targeted by my C# project. There was some mismatch it seems. The moment I upgraded the .NET Framework version of my project to latest, the Newtonsoft.Json package dependency and its reference came alive instantly.
Something I just noticed, and I'm not sure if this will help you or anyone else reading this, but this issue literally wracked my brain. The problem was that I was installing packages that I had created myself using NuGet Package Explorer on Windows.
It turned out that, I believe after updating NuGet Package Explorer, it was no longer putting DLLs that I included into the lib folder. Once I started manually adding the lib folder back into the package within Package Explorer, and then uploading to NuGet and reinstalling in the consuming project, that the reference would once again start to appear.
I'm not sure what caused this behavior - it could have been my own fault, but I literally just now figured this out - and consequently have to go back and re-do a whole bunch of NuGet package goodness that I've done over the past month. OUCH.
Hope this saves someone at least an ounce of pain.
None of the above worked for me.
What did work, was to edit the project file directly and delete the existing reference. When I reloaded the project, the package then showed up in references as a Nuget package.
I happened to come across the same problem. i tried all the possible solution but found the solution - just open the .proj file in an text editor and check the package Version and the HintPath in the Reference tag. Sometime there is an mismatch correct it then Visual studio will recognize. I hope everyone can save lot of time. Here is an sample to refer
<Reference Include="nunit.framework, Version=3.4.1.0, Culture=neutral, PublicKeyToken=2638cd05610744eb">
<HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>
Migrating to PackageReferences worked for me for the projects that allowed it. My Asp.Net project could not be migrated, so I resorted to manually adding the references to the .csproj file
I setup an internal NuGet server to host internal dll packages. The setup went smoothly. The spec and nupkg were created successfully. However, when I launch a test project and attempt to install it from Manage NuGet Packages it fails.
The internal package shows up under Manage NuGet Packages with an install button. I hit install but it does nothing. I check my references folder and saw nothing added.
If I check the Manage NuGet Packages at solution level, it has a green check mark indicate that it's installed but doesn't give me a Manage option to see which project it was installed to.
My issue is somewhat similar to this post below. The only difference is that I don't have sub folders for my library. I just have 1 dll and I'm putting the nupkg file directly under the Packages folder.
NuGet package fails to install
I'm not sure what I did wrong. Any suggestions?
Thanks to #MattWard for mentioned that the package got installed at the solution level. I went back to the official documentation here: https://docs.nuget.org/create/creating-and-publishing-a-package to review the differences with creating solution level package vs project level package and most important of all is the nuget naming convention when creating packages (the lib, content, etc. folder). I re-package my dll again with the naming convention and it works!