I believe you can also make nuget packages for your own libraries that you include in your projects, which means that your library is only in source control once, as the project itself. You may need a corporate nuget server for this, I'm not 100% sure.. On 26/01/2012 9:46 AM, "David Burela" <david.bur...@gmail.com> wrote:
> I don't understand how it makes anything trickier. > Deployment is easy, all the assemblies are set as "copy local = true". > having 3mb of files isn't a problem with source control, but there are > strategies around how you can make it NOT check those files in if you are > worried. > > > On 25 January 2012 17:53, Greg Keogh <g...@mira.net> wrote: > >> 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**** >> > >
