sdk: Dotnet restore does not honour nuget.config 'repositoryPath'

@emgarten Thank you, I think that clears up the issue.

To confirm, creating a config as follows

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

and performing dotnet restore at the root of a solution restores packages to c:\packages

I can also confirm that performing restore in Visual Studio also recognised the configuration and restored to the configured path.

Question: Setting the value to simply packages (or any relative path) creates a packages folder relative to the project.json for each project in a solution that is restored. Is that expected behaviour?

I think dotnet and nuget in general prefer using the NUGET_PACKAGES environment variable now.

Did this break the design according to https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior ??? The way it works now is very confusing for people trying to upgrade to project references and get rid of legacy project.json and package.config files.

Personally I think the documented design is better with a clear separation of the setting name when used in the solution/project relative (NuGet.config) or default “global” scope (NuGetDefaults.config). Perhaps you didn’t take this local/global split into account when “not respect”-ing it (also a strange thing to say). Who controls the design and what is removed, because right now there is a regression in functionality that was put there (I presume) for a good reason.

We know packages.config is legacy and also now project.json is also legacy (according to from sources like https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj). So here I am trying to upgrade my VS2017 solutions to the current technologies and it’s not consistent and us devs are wasting time trying to figure it out (not as documented). Please rethink, perhaps the behaviours with/without all the different possible package/project configuration files need to be in the unit tests, because at least one very common situation got past the team here.

Perhaps restoring the respositoryPath would be the best, at least for another few major releases, until all the existing documentation and solutions which used it already had a chance to move to the design change you just made.

Just to reiterate again on how nuget works here, in nuget.config: packages.config uses repositoryPath project.json uses globalPackagesFolder

As @yishaigalatzer mentioned mixed mode is the reason these have to be separate. Packages.config and project.json use different folder structures, so restoring an entire solution to a single packages folder would cause problems if the solution contained both types of projects.

@vcjones day to day development is going to be incredibly tedious having to set an environment variable every time you change solutions and want to restore/build.

What happens if two different feeds dump packages into the same location and possibly cause conflicts?

I should be able to do a nuget restore for any solution and not affect the on disk packages for another. It’s an option that already exists but would appear to have been removed in dotnet restore

This issue can also be reproduced with a global NuGet.config in e.g. (Windows) C:\Users\<name>\AppData\Roaming\NuGet\NuGet.config - A Visual Studio package restore will honour this config, dotnet restore does not.