Shared Nuget package repository for different Visual Studio Solutions

To avoid having the same Nuget packages in a development project, when the project consists of multiple Visual Studio solutions (.sln files), it is possible to configure Nuget to use a shared repository.

This is done by changing the default packages path to something else.

For existing solutions and projects depending on packages in the default path, the hintpath in the C# projects files (.csproj) needs to be changed to point to the new packages folder.

Note: This requires your Visual Studio solutions to have automatic Nuget Package Restore enabled. Otherwise you won’t have the Nuget.config file. You can enable Nuget package restore, and don’t use it – you just have to make sure that you have the correct packages in the shared Nuget package repository, and check them in to your version control system.

Changing the Nuget package path

Each project that uses Nuget has a .nuget folder on the same level as the solution file:

In the .nuget folder is a file called Nuget.Config.

The file normally looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <solution>
    <add key="disableSourceControlIntegration" value="true" />
  </solution>
</configuration>

The file should look similar to this after changing it:

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
  <solution> 
    <add key="disableSourceControlIntegration" value="true" /> 
  </solution> 
  <config> 
    <add key="repositorypath" value="$\..\..\..\libs\nugetpackages" /> 
  </config> 
</configuration>

The new config element with the repositorypath parameter define the location of the packages.

Note that the path should be relative, it must start with $, and the starting point of relative path is the .nuget folder.

You can test the change, by deleting the default packages folder in the solution, and running this command line from the .nuget folder:

nuget -restore ..\yoursolution.sln

This will download the required packages. The packages should be downloaded to the new location.

Changing existing projects to point to the new nuget package location

When you have downloaded the packages to the new location, you need to change those projects that look for the referenced packages in the old location.

One way to do this is to open the solution and check the References in all projects. If some of them can’t be found, they are probably those which are now located elsewhere.

To fix this, open the .csproj file in a text editor and look for <HintPath> elements which point to ..\packages. For example:

<Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"> 
  <SpecificVersion>False</SpecificVersion> 
  <HintPath>..\packages\EntityFramework.6.0.1\lib\net45\EntityFramework.dll </HintPath> 
</Reference>

The relative path in the <HintPath> element needs to be changed to the new location. Note that the relative path originates from the .csproj file.

<Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"> 
  <SpecificVersion>False</SpecificVersion> 
  <HintPath>..\..\libs\nugetpackages\EntityFramework.6.1.0\lib\ net45\EntityFramework.dll</HintPath> 
</Reference>

When you have changed the .csproj file and reloaded the solution in Visual Studio, it should no longer have problems finding the referenced nuget packages.

Test it

To test the change, delete the original packages folder located in the same file as the .sln file, and do a re-build. This should re-download the Nuget packages to the new location. If the packages folder re-occurs in the solution directory, you haven’t changed the nuget.config file correctly. If the packages folder is created somewhere else, you probably haven’t entered the correct relative path to the packages folder.

If the build fails because of missing references, you haven’t changed the .csproj files correctly.