Nuget Automatic Package Restore and custom sources

Question

It looks like the MSBuild nuget restore approach is no longer recommended

Also see: How do I Enable NuGet Package Restore in Visual Studio 2015

In the past we have put custom package sources in the .targets or .config files for the nuget packages to ensure that everyone uses the custom sources even with a vanilla VS install. It means less config on build servers ect.

EG in nuget.config:

  <packageSources>
    <add key="NuGet official package source" value="https://nuget.org/api/v2/" />
    <add key="Another Package source" value="https://another.package.source/nuget/" />
  </packageSources>

However with Automatic Package Restore there is no longer a .targets or .config file to put extra sources in. Is there another place we can put additional sources so that nuget will use them without needing the source set up manually on every machine building the project?

Answer 1

David Ebo made a post a while back that describes how to get this to work:

http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html

You will need to create a NuGet.Config file at the same level as your solution .sln file. The contents of the NuGet.Config file contain you custom sources.

I tried this, and it does indeed work; however, I noticed that I had to close and reopen the solution in order for the config changes to take effect.

Additionally, I included it in the solution as a solution item, although I doubt that is necessary.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
    <add key="MyCustomSource" value="https://myServer.com/CustomSource/nuget" />
  </packageSources>
</configuration>

Answer 2

I have looked for something similar and not found it. While the new auto package restore approach is much simpler than before, it loses the ability to store custom nuget package sources with the solution. Instead, it relies on the configuration file %AppData%\nuget\nuget.config.

This is not such a big deal for development workstations: each developer needs to know to update their package sources if there are custom nuget repostories. In my experience though, it is more of a hassle for build servers. Here's my somewhat imperfect solution for build scripts on build servers.

For formal builds, I use a small MSBuild script that restores packages and then builds using the Visual Studio generated MSBuild files.

Here is an example of a msbuild file that is about as simple as it gets. The most important part for this discussion is the <Exec> element that runs nuget restore.

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
  <PropertyGroup>
    <SolutionDir>$([System.IO.Path]::GetDirectoryName('$(MSBuildProjectDirectory)'))\</SolutionDir>
    <Configuration>Release</Configuration>
  </PropertyGroup>
  <PropertyGroup>
    <ToolsDir>$(SolutionDir)tools\</ToolsDir>
    <NuGetDir>$(ToolsDir)nuget\</NuGetDir>
  </PropertyGroup>
  <PropertyGroup>
    <SolutionProperties>
      Configuration=$(Configuration)
    </SolutionProperties>
  </PropertyGroup>
  <Target Name="Build">
    <Exec Command="$(NuGetDir)\nuget.exe restore -ConfigFile $(NuGetDir)nuget.config" WorkingDirectory="$(SolutionDir)"/>
    <MSBuild Projects="MyProject.sln"
             Properties="$(SolutionProperties)"
             Targets="Clean;Build">
    </MSBuild>
  </Target>
</Project>

The nuget restore command references a configuration file that specifies the package sources. Here is a sample nuget.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <packageSources>
    <add key="Custom MyGet" value="https://www.myget.org/F/myrepo/api/v2" />
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Note that I also keep a copy of nuget.exe in the same directory as the config file. I find it easier to have this in VCS rather than rely on the build machine having nuget.exe in a particular location. (nuget.exe does not seem to ship with VS2015, unless I'm mistaken).

I know this is probably not the nice, simple solution you were hoping for. I'd be interested if anyone else has come up with a better solution.