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.
Comments: 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.
<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.
Comments: 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.