Greg For the last few years, all the projects that I have worked on have had a "libs" or "dependencies" folder that is included in the source code.
It's a practice that has come from the Java world, one that I like. It avoids conflicts in updating libraries, and all team members have the correct version of the dll from source control. Davy Hexed into a portable ouija board. -----Original Message----- From: "Greg Keogh" <g...@mira.net> Sender: ozdotnet-boun...@ozdotnet.com Date: Wed, 25 Jan 2012 17:53:14 To: 'ozDotNet'<ozdotnet@ozdotnet.com> Reply-To: ozDotNet <ozdotnet@ozdotnet.com> Subject: The way NuGet works People have been talking about NuGet a bit so I thought I'd try it out. The very first thing that confused me was the relationship between the NuGet packages I install and those that I have already installed by other means. For example I get packages for Entity Framework, Nunit and SQL CE, but I already have these installed. So I opened a small console app and added the NUnit package to see what happens. I see that it adds 3 references like this sample: E:\dev\command\myapp\packages\NUnit.2.5.10.11092\lib\nunit.framework.dll Then I see that it has created a packages folder under my solution folder containing 55 files in 4 folders with a total size of 3.8MB. Now this seems a bit heavy-handed ... it will create duplicated and redundant files in projects everywhere, multiple tool versions can be installed, and it will make version control and deployment trickier. I'm utterly bewildered by what NuGet has done and find it hard to believe that anyone would find this acceptable. Am I missing something? Greg
