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
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
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="globalPackagesFolder" value="packages" />
</config>
</configuration>
nuget restore behaves as expected, but dotnet restore does not. 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.
globalPackagesFolder is working for me with preview2.
.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
<?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>
dotnet newdotnet restoreAll 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:
dotnet --info outputC:\Projects\Git\dmumladze\CardGames\src\lib\project.lock.jsonC:\Projects\Git\dmumladze\CardGames\NuGet.ConfigC:\Users\dm32998\AppData\Roaming\NuGet\NuGet.ConfigFrom 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..
@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.
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
.dotnetSentinelfile in your default location.This is already a known issue I believe.