Why isn't there any packages folder in my .NET Core solution's containing folder?

Question

Are packages now cached in a more shared location somewhere or what?

My solution folder is devoid of any packages folder:

Solution 1

Per project: References->Nuget dictates what packages are referenced and restored. But, as Eastrall mentioned, the packages folder is now global and located in your user folder: C:\Users\[YourUsername]\.nuget\packages

Solution 2

To force ./packages folder for Solution

To force download of packages folder to be a child of the solution folder for .NET Core projects, follow these steps:

1. Create a NuGet.Config file in the same directory as the .sln file.

2. Copy the following contents into the NuGet.Config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value=".\packages" />
  </config>
</configuration>

3. Configure NuGet to download missing packages by:

   3.1. In Visual Studio: Tools -> Options

   3.2. Filter by nuget (top left in dialog). Select General

   3.3. Ensure Allow NuGet to download missing packages is checked

3. Close and re-open the solution. NuGet will download the required packages.

---

Note: the NuGet.Config configuration can also be achieved by executing the following command from the NuGet Package Manager Console (Tools -> NuGet Package Manager -> Package Manager Console):

PM> nuget config -set globalPackagesFolder=.\packages -configfile "$(pwd)\NuGet.Config"

Solution 3

You still have packages folder in your .NET Core solution, but the global packages are located at: C:\Users\[YourUsername]\.nuget\packages

Solution 4

You can check out a question I asked to see if the answers do you any good.

How do I include NuGet packages in my solution for .Net Core projects?

You can get that packages folder back, but you might not be happy with the results, since .Net Core projects rely on so many NuGet packages. Mine is hovering around 1 GB.

https://docs.microsoft.com/en-us/nuget/schema/nuget-config-file#config-section

View more solutions

Comments

[ProfK]

Oh, I ever so sarcastically wonder what that downvote was for, just after I added more information to make my question clearer.

[Yuriy Anisimov]

Again such a bad architectural decision from Microsoft - we kind of back to GAC :( - instead of container approach...

[MSC]

It's an interesting approach, for sure. Not as bad as GAC, the idea was that your PC/user can cache the collection of packages referenced across many projects and solutions. It's a storage-saving enhancement. Its actually helpful if you work in many projects. There's no "run-time resolution", they just consolidated package folders into one package folder at the user-level.

[Yuriy Anisimov]

True - but another side of the coin dev and prod (deployed) are different - I'll bet on it that there would be some issues... :) - I'd love to opt it in or opt it out - that would be gr8! For sure there are following advantages:

[Yuriy Anisimov]

1. Less load on the nuget server. 2. Less local space consumption. 3. Build time optimization - no copying any nugets to bin folder.

[Hans Løken]

@GeorgeAnisimov Dev and prod will not be different as long as you use '--self-contained true' with dotnet publish on the build server. I do this as part of creating deployment-packages.

[FelipeDrumond]

I had a little more work - had to add nuget.org api address <configuration> <config> <add key="globalPackagesFolder" value=".\packages" /> </config> <packageSources> <add key="nuget.org" value="api.nuget.org/v3/index.json" protocolVersion="3" /> </packageSources> </configuration>

[dan]

In case where some content needed to be copied from the package folder (as a build activity may be), its best to have the content relative to the sln. In that case, @CJBS approach will work better.

[Joelty]

@GeorgeAnisimov anyway it's an improvement over packages folder

[Stanley Backlund]

God Tier answer. Fixed my intranet deployment issues.