0 Comments

I’ve struggled lately with Nuget at work. Let me preface this by saying that I really like Nuget  and when it works, it’s fantastic. 

So here’s the scenario - a small development team, working on multiple applications, all of which have “Enable Nuget Package Restore” enabled and share a few common libraries. I’m working on an Web API project and add the first Nuget reference into one of the shared assemblies, then check in. Now another developer gets latest in a webforms solution that uses the library that I just checked in and it throws errors about not being able to find the Nuget reference. This has bitten me a few times now. 

I looked at the packages.config file, saw it looked perfect, and was left scratching my head. If any of the other developers delete the reference and add it again, things work just fine. Here’s what went wrong. At the same level as the solution file is the packages folder. This is part of why you have to typically create solutions in their own folder, or else when you enable package restore on multiple solutions that are in source control in the same directory, they battle for supremacy of that directory and the .nuget directory. Within the packages folder is a file called repositories.config that controls which projects in a solution need to have packages restored in. When you add the first Nuget package to a project in a solution, it only modifies the repositories.config file in that solution. So any other solutions that reference the project that just got Nuget-ified aren’t aware they need to restore the package to that project, and since the reference isn’t present on your fellow developers machine, it can’t compile.

The best solution I can find is to locate all of the solutions that reference the project in question and manually add it to the repositories.config file. Yuck.