This is a guest post from Scott Decker.
Our team recently migrated some client projects over from Team Foundation Server to Team Foundation Service (TFS). Connecting to TFS and porting the code presented little challenge. Once the builds were set up, we encountered the real trouble: missing dlls. Yes, “Enable Nuget Package Restore” was selected. Yes, nuget.exe had been added to source control. Yes, I had checked the version of the nuget packages to see if an update had messed something up. All to no avail. The key lied in repeating a process we normally execute locally the first time we download a new solution from source control.
When the solutions were first built locally, there were tons of errors concerning missing dlls (see below). We had to close Visual Studio, delete the “packages” folder locally, reopen the solution, and rebuild. Tada.
With Nuget, you don’t have to check in the packages folder. Nuget should be able to tell which packages it needs and download any missing ones. This functionality, however, wasn’t working on the build server just as it wasn’t working on the local machine. The error (below) was a little different but the root issue was the same: missing packages.
The solution ended up being remarkably simple: repeat the steps we perform locally in source control.
- In Visual Studio, open the Source Control Explorer.
- Navigate to the packages folder (it should be on the same level as the projects in the solution).
- Right click and select “Delete”. A small red x should appear next to the name.
- Check in the pending change (deleting the packages folder) and wait.
If all goes well, that automatic build should kick off with the new check in and build successfully.
Note: the first build should take longer than usual as the server has to recreate the packages folder and download all packages.