I’ve been trying to untangle the snarled mess that results from the old Nuget “Enable Package Restore” option. It would seem to be very simple for most things according to the official doc. And for most projects, it is exactly that easy. The problem I kept having after following the TFS steps was that no matter what I did, the Nuget.targets import line would add itself back into any web application project I removed it from. Open the .proj file, remove the line, and as soon as you reload the project, it adds the import node back in. It seems to stick more with web projects for some reason. Here’s the fix:

1. Kill the entire Nuget folder at the solution level.
2. Despite doing that, I had to open the .sln file in notepad and delete out the nuget block at the top.
3. Now open the web application .proj file and delete out the nuget.targets import line.
4. Also look for a RestorePackages node and delete it out. This will be towards the top.

Now when you reload the project file it will finally let the Nuget references go. And don’t even get me started on getting the package restore during team build on TFS working after this. Is this really the best solution?

It looks like there’s a pretty glaring hole in the Visual Studio 2013 preview that was released at Build relating to Nuget Package Restore. So you pull down a solution where Enable Package Restore was set into VS 2013 from source control and try to compile. None of the Nuget packages get restored, so the project doesn’t compile. No joke, you have to reinstall all packages to get it to work. That’s “Update-Package -Reinstall” from the Package Manager Console. I hope this gets fixed soon, and definitely before it goes to RTM.

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.