Home: global.json cannot isolate the packages folder per project

Created on 8 Apr 2016  路  26Comments  路  Source: NuGet/Home

I have a solution with global.json:
./global.json

{
    "projects": [ "src", "test" ],
    "packages": "bar"
}
`

in the root of the solution I run: 
$ dotnet restore

Expected: the folder foo is created in the current directory, and it contains the packages
./bar/**  <-- packages here 
./src/ClassLibrary1/project.json
./src/ClassLibrary2/project.json

Actual: the setting has no effect. Solutions cannot opt-into dependency isolation.


Discussion: We have a feature like this in nuget.config, we need to decide if we want to keep both
Bug

Most helpful comment

I think what you are seeing is dotnet not respecting the nuget.config globalPackagesFolder value.

This happens during: A command is running to initially populate your local package cache, to improve restore speed and enable offline access. which is not part of NuGet restore.

You can avoid it by keeping the .dotnetSentinel file in your default location.

This is already a known issue I believe.

All 26 comments

Talking with @davidfowl we will drop the packages feature from global.json and keep it only in nuget.config to avoid duplication.

The path should be relative to the nuget.config on disk

Neither nuget.config nor global.json honors the relative path of packages folder. What is the current state of the issue?

Packages folder can be isolated using nuget.config per solution (but not per project unless you restore each individual project with dotnet restore).

From: https://docs.nuget.org/ndocs/schema/nuget.config-file#config-section

globalPackagesFolder
(project.json only) The location of the default global packages folder. The default is > %userprofile%.nuget\packages. A relative path can be used in project-specific nuget.config files.

So IMHO this is resolved already, and the issue should be closed.

@karann-msft can we please update the docs to reference packageReferences scenarios as well (instead of just project.json)

@rrelyea @emgarten - Let me know if you think I'm missing anything here.

@dmumladze - You should use at least nuget.exe 3.5

global.json will not be supported going forward

I'm using

**_NuGet 3.5.0.1938
.NET Core  1.0.0-preview2-1-003155
Visual Studio Code 1.8.1
C# Extensions 1.5.3_**

I have a solution setup at
_C:\Projects\git\dmumladze\solution1_

with nuget.config

**_<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
</configuration>_**

and global.json

**{    
    "projects": [
        "src",
        "test"
    ]
}**

but packages are still generated under C:\Users[username].nuget\packages whether I execute _nuget restore_ or _dotnet restore_

I don't have Visual Studio 201* at all.

That's because you are using "repositoryPath" instead of "globalPackagesFolder"

@yishaigalatzer only nuget restore will honor that and not dotnet restore, correct?

both will

EDIT - I'll find out which exact version is needed as a minimum, but I think preview2 will support it already

dotnet restore ignores it and still generates under C:\Users\user.nuget\packages.

hmmm, I'll double check. Can you validate two things for me

  1. Share your nuget.config
  2. nuget.exe restore behaves as expected or not?
  3. The config file is at the solution level (so one folder above the project)
  1. Content of nuget.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value="packages" />
  </config>
</configuration>
  1. Yes, nuget restore behaves as expected, but dotnet restore does not.
  2. Solution folder structure
     Root: C:\Projects\Git\dmumladze\CardGames\
     Nuget.config at C:\Projects\Git\dmumladze\CardGames\nuget.config
     Project 1 under C:\Projects\Git\dmumladze\CardGames\src\lib
     Tests under C:\Projects\Git\dmumladze\CardGames\tests\lib.tests

That's unexpected because they share the same codebase... I'll look into it and get back to you

Can you share the output from nuget.exe restore and dotnet restore (it should list config values, use verbosity flag if not enough).

It does look like you are using the right version of dotnet restore, so I'd like to see the logs and we can decide if we need to further fix it, or if it was fixed in a newer version. (or you can try this -https://www.microsoft.com/net/download/core#/current )

As a workaround you should be able to set the following environment variable - NUGET_PACKAGES

I downloaded and installed latest .NET Core CLI/SDK today. See attached of dotnet/nuget restore command.

nuget_restore.txt
dotnet_restore.txt

globalPackagesFolder is working for me with preview2.

dotnet --info

.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
 Version:            1.0.0-preview2-003131
 Commit SHA-1 hash:  635cf40e58

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

NuGet.Config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="globalPackagesFolder" value="d:\tmp\testPackages" />
  </config>
  <packageSources>
    <clear />
    <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

Steps

  1. Create a new folder
  2. Change to folder
  3. Create NuGet.Config
  4. Add globalPackagesFolder path to config.
  5. dotnet new
  6. dotnet restore

Result

All packages were restored to d:\tmp\testPackages

@emgarten I have a solution structure as per below and dotnet restore does not honor globalPackagesFolder but nuget restore does.

Root: C:\Projects\Git\dmumladze\CardGames\
Nuget.config at C:\Projects\Git\dmumladze\CardGames\nuget.config
Project 1 under C:\Projects\Git\dmumladze\CardGames\src\lib
Tests under C:\Projects\Git\dmumladze\CardGames\tests\lib.tests

@dmumladze would you share:

  1. dotnet --info output
  2. Contents of C:\Projects\Git\dmumladze\CardGames\src\lib\project.lock.json
  3. Contents of C:\Projects\Git\dmumladze\CardGames\NuGet.Config
  4. Contents of C:\Users\dm32998\AppData\Roaming\NuGet\NuGet.Config

From the output log it shows that the config you mention is being used.

dotnet --info

.NET Command Line Tools (1.0.0-preview2-1-003155)

Product Information:
 Version:            1.0.0-preview2-1-003155
 Commit SHA-1 hash:  d7b0190bd4

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64

And the rest attached in the same order as requested..

project.lock.json.txt
NuGet.Config.txt
NuGet.Config.txt

@dmumladze are there packages under C:\\Projects\\Git\\dmumladze\\CardGames\\packages?

As mentioned before, they are generated only with nuget restore, but not with dotnet restore.

The project.lock.json file you have contains

  "packageFolders": {
    "C:\\Projects\\Git\\dmumladze\\CardGames\\packages": {}
  }

Was that created by dotnet restore?

I do see some difference with how dotnet restore handles relative paths, I get the equivalent of C:\Projects\Git\dmumladze\CardGames\src\lib\packages The path is taken relative to the project instead of the config. This issue has been fixed in NuGet, and likely fixed in the nuget.exe you are using.

To work around it use an absolute path in your config file.

Yes, I'm using the latest nuget.exe v3.5.0.1938, whereas dotnet.exe is using 3.5.0.0 (from the logs it seems). I also noticed, that dotnet restore generates packages both under global and local folders.

Specifying absolute path works.

EDIT: Generating in both packages is OK. I just noticed there are also local deps in local packages folder, whereas global only contains global dependencies.

Should I open a separate issue for absolute path bug or you guys will take it from here?

I think what you are seeing is dotnet not respecting the nuget.config globalPackagesFolder value.

This happens during: A command is running to initially populate your local package cache, to improve restore speed and enable offline access. which is not part of NuGet restore.

You can avoid it by keeping the .dotnetSentinel file in your default location.

This is already a known issue I believe.

Was this page helpful?
0 / 5 - 0 ratings