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

[Kieranties]

Steps to reproduce

1. dotnet new in an empty directory
2. Add the following nuget.config to the same directory

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

1. dotnet restore in the same directory
   

   Expected behavior

Packages for the solution are restored to _c:packages_

Actual behavior

Packages for the solution are restored to _c:\users.nugetpackages_

Environment data

.NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde21225e

Runtime Environment:
OS Name: Windows
OS Version: 6.3.9600
OS Platform: Windows
RID: win81-x64

Additional

I understand that the packages path can be passed as an argument to the dotnet restore command, however this only works at the CLI level, what happens when Visual Studio does a restore?
Previously, the packages path could be provided in the global.json (for DNX/RC1 ASP.NET projects) but this also no longer works.

[anoordende]

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.

[vcsjones]

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

[Kieranties]

@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

[blackdwarf]

/cc @emgarten @yishaigalatzer

This to me looks like a NuGet issue.

[vcsjones]

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

I don't think the _source_ of a nuget package should be part of the identity of a package. If two packages have the same identifier, I would expect them to the the same package no matter where they come from.

Regardless, I'm not saying that repositoryPath in nuget.config shouldn't work and that there should be ways other than an environment variable to do it, but I do think it's a poor practice to use the package source as part of the identity of the package.

[yishaigalatzer]

Here is where it stands

1. The source is not part of the id. The model is the identity is id + version and that's it.
2. The repository path will never be respected. It is the path for packages.config based projects
3. We do have a nuget.config setting for the global packages folder. The CLI needs to pick it up, there is no nuget work to enable it, so this issue does belong here.

Get Outlook for Androidhttps://aka.ms/ghei36

On Thu, May 19, 2016 at 1:41 PM -0700, "Kevin Jones" <[email protected][e-mail]> wrote:

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

I don't think the source of a nuget package should be part of the identity of a package. If two packages have the same identifier, I would expect them to the the same package no matter where they come from.

Regardless, I'm not saying that repositoryPath in nuget.config shouldn't work and that there should be ways other than an environment variable to do it, but I do think it's a poor practice to use the package source as part of the identity of the package.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/cli/issues/3135#issuecomment-220441863

[blackdwarf]

/cc @piotrpMSFT

[Kieranties]

@vcsjones I completely agree that two packages with the same identifier should be the same package, no matter the feed. However when the feed is not managed by yourself and two feeds provide different versions of a package, always using a global packages folder introduces problems. (Appreciate your response just highlighting the issue I'm trying to prevent)

e.g. we had several scenarios when changing feeds from aspnetrelease/master/cidev etc with projects referring to 1.0.0-* versions. Restoring packages for a project using the master feed, where another project has restored a newer version from a different feed into the same global cache, caused the newer package to be picked up during a project restore. The project would now be referencing a package that it would never have received if it had it's own localized packages folder which only restores the packages from its configured feeds.

Additionally, the use of a project specific (or nuget.config specific) packages folder ensures that when clearing those packages only that project is affected. Currently, one would always have to clear the global cache (or env variable location cache).

The repository path will never be respected. It is the path for packages.config based projects

@yishaigalatzer so the repositoryPath is now deprecated when using project.json?

[yishaigalatzer]

It is not deprecated, you can have a solution that mixes both modes, repositorypath refers only to packages that introduce a relative path.

Get Outlook for Androidhttps://aka.ms/ghei36

On Fri, May 20, 2016 at 12:43 AM -0700, "Kieranties" <[email protected][e-mail]> wrote:

@vcsjoneshttps://github.com/vcsjones I completely agree that two packages with the same identifier should be the same package, no matter the feed. However when the feed is not managed by yourself and two feeds provide different versions of a package, always using a global packages folder introduces problems. (Appreciate you're response just highlighting the issue I'm trying to prevent)

e.g. we had several scenarios when changing feeds from aspnetrelease/master/cidev etc with projects referring to 1.0.0-* versions. Restoring packages for a project using the master feed, where another project has restored a newer version from a different feed into the same global cache, caused the newer package to be picked up during a project restore. The project would now be referencing a package that it would never have received if it had it's own localized packages folder which only restores the packages from its configured feeds.

Additionally, the use of a project specific (or nuget.config specific) packages folder ensures that when clearing those packages only that project is affected. Currently, one would always have to clear the global cache (or env variable location cache).

The repository path will never be respected. It is the path for packages.config based projects

@yishaigalatzerhttps://github.com/yishaigalatzer so the repositoryPath is now deprecated when using project.json?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/dotnet/cli/issues/3135#issuecomment-220539359

[emgarten]

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.

[Kieranties]

@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?

[emgarten]

relative to the project.json for each project in a solution that is restored. Is that expected behaviour?

It is expected to be relative to the solution root, but with dotnet restore from the command line there is no solution.

I think this NuGet behavior needs to change to make this easier to use, I've opened https://github.com/NuGet/Home/issues/2831 to track it. Please add any comments there if you expect it to work differently than described.

[blackdwarf]

Is this issue OK to be closed then?

[Kieranties]

@blackdwarf I think so, @emgarten response made it clear that repositoryPath is not respected by design (and for good reason)

I'll pick up the discussion on issue https://github.com/NuGet/Home/issues/2831

[CodeChief]

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.