NuGet and TFS Best Practices

Question

Our projects at TFS are organized as follows:

$\DefaultCollection\ProjectName\Source <-- source code goes here $\DefaultCollection\ProjectName\SharedAssemblies <-- 3rd party binaries go here 

Now that NuGet is on stage, is there any reason to change our approach and use the NuGet package folder for DLLs that come from projects that support NuGet? I lean against it because

1) it creates two places to look for dependencies 2) it leaves us open for one developer updating the package and breaking some dependency

However, if someone can report a good reason to start using NuGet in a TFS environment, I am happy to present my ideas to my team as if they were mine (just kidding).

Answer 1

Nuget 1.6 now allows you to download packages non-dynamically after assembly. Thus, now you can register in the source element without a DLL, but the assembly itself will pull the correct package.

http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages