After several months of successful builds using the online TFS build server (part of Visual Studio Online) I encountered a new issue with NuGet Package Manager that had me frustrated for some time this week. The build worked great on my machine, but consistently failed on the build server.
This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=317567.
The error message contains a link (also available here) to more information about the root cause for this error – but the proposed work around for use with a hosted TFS / CI environment didn’t leave me with any obvious actions to fix this problem.
This solution doesn’t address build server / continuous integration (CI) scenarios. In order to successfully use package restore on the build server, you have two options:
- Check-in the .targets file.
- Explicitly run NuGet package restore prior to building your project/solution.
Unfortunately this article didn’t lead me to an obvious resolution;
- Adding the .targets file to source control above looked easy enough, but after a quick search the application directories for an appropriate .targets file no obvious candidates were found. There were a number of .targets files within specific packages, however none seemed to immediately stand out as the one being referred to.
- Some basic investigation into the option of forcing TFS to run the NuGet Restore also failed to lead to any way to execute the NuGet packages from within the hosted environment.
It turned out that a number of folders within the NuGet Packages folder were not correctly in source control, including a number of Application Insights folders and the Microsoft.Bcl.Build package.
Adding all NuGet package folders to source control may have been overkill … but it has solved the problem. Admittedly this is simply a brute force approach to perform the action recommended by the MSDN article (several .targets files were checked in as part of this operation), but the upshot is that although the article does technically describe the action required it still took over a month worth of TFS Build credits to move past the error.
I’m still unclear on the exact change that caused the issue, but my suspicion is that this was caused by a corrupted project file as a result of a couple of TFS Rollback operations.