Custom globalPackagesFolder in NuGet.config is not used by msbuild

[rainersigwald]

Migrated from original issue by @robpex at dotnet/msbuild#1861.

I found this question on StackOverflow which describes, more or less, the same problem I'm experiencing.

http://stackoverflow.com/questions/35307155/use-solution-relative-packages-folder-with-nuget-and-project-json

Basically, if you're using a custom globalPackagesFolder in your NuGet.config, msbuild is not looking in that directory. My workaround is adding "/p:NuGetPackagesDirectory=$(Build.SourcesDirectory)\Packages" to the msbuild arguments.

I couldn't find this anywhere on GitHub and it took me a while to see the suggestion of adding that argument on StackOverflow, so I thought I would go ahead and create a ticket here.

[rainersigwald]

Possibly related: #3876, #4341.

[emgarten]

Thanks for reporting this issue. We have not been able to reproduce this issue. If you are still able to reproduce this with the latest NuGet version, please provide additional steps.

[daveaglick]

I am able to reproduce this. Here is my NuGet.Config file, placed alongside my .sln:

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

I've tried lots of different variations for the value of globalPackagesFolder including absolute paths. MSBuild appears to ignore all of them. The solution contains two SDK-style projects. One targets .Net Standard 1.5 and the other .NET Core 2.0.

NuGet Version: 4.3.0.4406
Visual Studio 15.4.4

[emgarten]

@daveaglick is the value of packageFolders correct in obj\project.assets.json?

[daveaglick]

Nope - here's what I've got after closing VS, deleting the obj folder, reopening VS, and rebuilding:

  "packageFolders": {
    "E:\\NuGet": {},
    "C:\\Program Files\\dotnet\\sdk\\NuGetFallbackFolder": {}
  },

("E:\NuGet" is my global default, so that's not unexpected if the local config isn't working)

[emgarten]

E:\NuGet" is my global default

Where did you define this? Your user wide nuget.config?

[daveaglick]

Well this is odd - I can't find it anywhere. I thought it was defined in "%APPDATA%\NuGet\NuGet.Config" which contains the rest of my settings, but it's not in there. I also checked all the other possible config locations according to https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior#config-file-locations-and-uses and can't find a config file that adjusts the default package folder. I also checked the folder tree up to the root just to be sure there wasn't one hiding in those search paths.

I'm guessing this has something to do with not processing the local solution config file. Is there somewhere else that could be taking precedence (even though it's not supposed to)?

[jainaashish]

Can you also check if the environment variable NUGET_PACKAGES is set? this is another way to set the global packages folder.

[daveaglick]

@jainaashish I does look like I have that set:

Must have picked it up along the way and not remembered.

So I think there are a few questions/problems here:

• Should the NUGET_PACKAGES environment variable (and other environment variables) take precedence over any of the NuGet.Config files? If so, that should be documented on the page at https://docs.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior#config-file-locations-and-uses. However, my opinion is that the environment variables shouldn't take precedence over a local NuGet.Config file, otherwise there's no way to change these settings on a project-by-project basis if the environment variable is set.
• The available environment variables in general should be better documented. The only place I found a reference to this one was at https://docs.microsoft.com/en-us/nuget/tools/cli-ref-environment-variables. That page is specifically about the CLI, but clearly these environment variables impact more than the CLI since they're also being used by the NuGet MSBuild targets.

[emgarten]

👍 on docs

Env var wins over nuget.config files. These are typically used by a CI to override things without modifying files, it should probably keep this precedence.

https://github.com/NuGet/NuGet.Client/blob/2c4e39c5c5cd52c7a2739fdcfd6bd2b212212cd1/src/NuGet.Core/NuGet.Configuration/Utility/SettingsUtility.cs#L132-L161

[daveaglick]

These are typically used by a CI to override things without modifying files, it should probably keep this precedence.

That makes perfect sense, agree it should stay. So just needs to be well documented.

[emgarten]

I've opened a doc bug to track this here: https://github.com/NuGet/docs.microsoft.com-nuget/issues/578