16

Closed

When package restore does not honor "repositoryPath"

description

In my Nuget.config I have specified a repository path:
<config>
<add key="repositoryPath" value="C:\Shared\Packages" />
</config>

When I install a package it correctly places the exploded files in this directory.
If I enable the package restore capability it does not honor the "repositoryPath" and instead restores the packages to a packages folder in the same directory as the .sln file. This is problematic on a build server.
since my .csproj references expect those files to be in the "C:\Shared\Packages" directory and since they are not restored to the correct directory the build will fail.
Closed Sep 29, 2013 at 10:32 PM by feiling
Customer reported that the problem was fixed.

comments

howarddierking wrote Dec 20, 2012 at 10:39 PM

@ClayCompton - can you repro?

ClayCompton wrote Dec 21, 2012 at 1:40 AM

@howarddierking - Yes, this repros in the 2.2 release in an MVC app.

chekm8 wrote Dec 21, 2012 at 12:29 PM

I did a bit more looking into this and have some additional information. The problems is that when you enable package restore the NuGet.targets file has a hard coded OutputPath in the <RestoreCommand> I would think that this should first search for a defined repositoryPath and use that if not defined then use the current project directory. If you remove the '-o "$(PackagesDir)"' from the script the nuget command is working correctly and places them in the repository as specified in the nuget.config.

One other side note, The help for the for "nuget help install" should be changed so the -OutputDirectory states something like "Specifies the directory in which packages will be installed. If not specified, it will search for a repositoryPath defined in the Nuget.config hierarchy. If it does not find a defined repositoryPath it will use the current directory."

danthman wrote Jan 2, 2013 at 11:11 PM

I can repro. Also, please see:
http://nuget.codeplex.com/workitem/1990

mrmikal wrote Jan 14, 2013 at 6:16 AM

I definitely verified that what @chekm8 wrote on Dec 21, 2012 is the case with version 2.2. If I remove the '-o "$(PackagesDir)"', it will restore packages to the correct folder specified in the nuget.config, and make the proper changes to the references.

DoggettCK wrote Jan 18, 2013 at 12:12 AM

I was able to repro it in 2.2.31210.9045. I modified NuGet.targets and nuget.config to point to C:/External/Packages, deleted C:/SolutionDir/Packages, and restored, only to find it always reinstalling under SolutionDir. Running nuget.exe install in SolutionDir/.nuget respected the correct directory.

What finally fixed it for me was doing the above, then deleting references to SolutionDir/packages, restarting Visual Studio and restoring again. Then I had to compile and manage the references through the NuGet UI and re-add them to certain projects. I think for some reason VS had cached where it should be saving the packages. After the restart, everything's working perfectly.

FilipDeVos wrote Jan 28, 2013 at 11:28 AM

This is the same issue as reported here http://nuget.codeplex.com/workitem/1990

deepakverma wrote Feb 22, 2013 at 12:05 AM

Reopening this issue. There are two problems here
A) If NuGet.config is placed in the project it doesn't read the settings.
 Repro:
     1. create new console app
     2. Create NuGet.config at project level.
     3. add the repositorypath setting to point to c:\temp
     4. Close and reopen the solution
     5. install a package
Actual:
package is installed in default packages dir
Expected:
As per the doc it looks in the following order. 
    .nuget\nuget.config
    Recursive walk from project folder to root
    Global nuget.config (%appdata%\NuGet\nuget.config)
So it should have looked at the project folder, read the repostitorypath setting and downloaded the packages there
B)
It's a pain and not discover-able by many to close and reopen the solution to get the setting refreshed.

koistya wrote Aug 9, 2013 at 5:18 PM

My solution file is located in .\Source\Application.sln. I have the following setting in my .\Source\.nuget\NuGet.config file:

Image

But still, NuGet packages are restored in the default folder .\Source\packages instead of .\Packages:

Image

Any ideas how to deal with it? It seems like repositoryPath settings is ignored in the NuGet's UI panel.

koistya wrote Aug 9, 2013 at 5:21 PM

Using Visual Studio 2013 Preview (12.0.20623.01), NuGet 2.6.40529.71

feiling wrote Aug 10, 2013 at 12:18 AM

No repro with the latest NuGet extension. The packages are restored to the directory specified by repositoryPath, thru either UI or thru build.

My environment is:
  • VisualStudio Ultimate 2012, 11.0.60315.01 Update 2
  • NuGet VS Extension 2.6.40627.9000.
  • The version number of the nuget.exe installed in $(solution).nuget\ is 2.6.40619.9041.

koistya wrote Aug 10, 2013 at 9:01 AM

I double checked, it works for me during build (right-click on the solution > Rebuild Solution) but not via UI (right click on the solution > Manage NuGet Packages for Solution). Having the latest versions of VS 2012 and 2013, NuGet Extension, $(solution).nuget
  • VS 2012.2 (11.0.60610.01) + NuGet 2.6 (2.6.40627.9000) + $(Solution).nuget 2.6 (2.6.40619.9041)
  • VS 2013 (12.0.20623.01) + NuGet 2.6 (2.6.40529.71) + $(Solution).nuget 2.6 (2.6.40619.9041)

koistya wrote Aug 10, 2013 at 11:53 AM

Steps to reproduce:
  1. Create a new solution
  2. Right-click on the solution file in the solution explorer > Enable NuGet Package Restore
  3. Add repositoryPath setting into the .nuget\NuGet.Config file file as shown on the screenshot below
  4. Right-click on the solution > Add > New Project (for example, a C# console application)
  5. Right-click on the newly create project node in the solution explorer > Manage NuGet Packages > Add any package (for example, Json.Net)
Image

The package is downloaded into the default $(solution)packages folder ignoring repositoryPath setting in the .nuget\NuGet.Config file. But this takes place only via NuGet UI. If you build the solution repositoryPath from the .nuget\NuGet.Config is honored as expected.

dotnetjunky wrote Aug 10, 2013 at 12:17 PM

Fei, please try the new repro.

koistya wrote Aug 10, 2013 at 2:51 PM

...as a workaround, NuGet.config can be moved from $(SolutionDir).nuget to $(SolutionDir) folder in order to make NuGet consistently work both from a command line (MSBuild) and via Visual Studio UI.

KevinWatkins wrote Sep 5, 2013 at 10:00 PM

Unfortunately, I haven't been able to get this workaround to work.

For enterprises, it is very common to have many 100s of solutions and projects in a single source tree. It's not an option to store 100s of copies of the downloaded packages. Thus, this bug effectively precludes the use of NuGet in our environment.

feiling wrote Sep 18, 2013 at 11:40 PM

@koistya, with regard to the repro steps posted at "Aug 10 at 3:53 AM"

I noticed that between steps 3 and 4, you didn't close and reopen the solution, which means the settings you saved in step 3 did not taken effect. Thus, packages are still installed into $(solutionDir)\packages folder.

As mentioned by deepakverma, you need to close and reopen the solution for the new settings to take effect.

KevinWatkins wrote Sep 19, 2013 at 11:25 PM

With NuGet 2.7 and Visual Studio 2012 the repositoryPath config option seems to be working now both in the UI and with msbuild. Thanks.

EvilShrike wrote Oct 25, 2013 at 10:40 AM

I'm having this issue in VS2013 and NuGet 2.7!
During restore in VS UI packages are being downloaded into default location instead of folder specified in .nuget\NuGet.Config.
Command-list restore (nuget.exe restore xx.sln) works as expected.

JamesCrowley wrote Oct 25, 2013 at 12:48 PM

I'm also having the same issue in VS 2013 using the UI/VS PowerShell commands for installing/updating packages.

frankvaneykelen wrote Oct 29, 2013 at 11:46 AM

They issue has not been resolved for me too (VS 2013, Nuget Package Manager 2.7).

danliu wrote Oct 29, 2013 at 5:30 PM

There is a similar bug being reported for 2.7, https://nuget.codeplex.com/workitem/3521, which is to be fixed in release 2.7.2.

danliu wrote Oct 31, 2013 at 11:35 PM