Space is very cheap in our case, we do a lot of builds over a lot of machines, so we favor the ability to just enlist and build without anything other than an OS. On some of our build machines, they are also completely disconnected/isolated from the network/internet.
NuGet also forces you to version packages very strictly - so it's quite obvious what's occurring when you check-in a newer version. Perhaps if there was a private nuget server internally for our group where we published, I could see turning on package restore for it and avoid checking in the binaries. From: [email protected] [mailto:[email protected]] On Behalf Of Michael Minutillo Sent: Tuesday, September 25, 2012 10:04 PM To: ozDotNet Subject: Re: NuGet question You are making an assumption that NuGet will always be available and that the package you're using will always be up there. We had an issue recently where an outage with the NuGet feed resulted in failing builds on the build server. It worked fine for us because we all had the dlls locally. I'd argue that putting dlls into source control is fine if they aren't changing very often . Space is (reasonably) cheap and it does guarantee that you can always do a "Get Latest. Build". When they DO change a good check-in comment is sufficient (as opposed to full diffs) as it will usually say something like "Updated Caliburn.Micro to version 1.1". Michael M. Minutillo Indiscriminate Information Sponge http://codermike.com On Wed, Sep 26, 2012 at 12:52 PM, Stephen Price <[email protected]<mailto:[email protected]>> wrote: No, that's the point. You set Nuget to manage the packages on the build, then you check in the nuget config files (which tells it what packages you want it to manage/have installed). Then when it does a build it checks your solution has all the right packages and if not downloads and installs the dlls. So only thing you check in is the nuget config files that it adds to your solution. Checking in the package folder (and dll's) would be a waste. you might as well not use the package restore option and just check in your dlls. (which is what traditionally people do when they are not using nuget... ) On Wed, Sep 26, 2012 at 12:30 PM, mike smith <[email protected]<mailto:[email protected]>> wrote: I'm not trying to start a flame war (standard disclaimer) but isn't storing dlls in a source control system somewhat the wrong thing to be doing? Unless the source control is very smart about DLLs, it's going to store a total new dll every time you checkin new dlls, and your ability to see what's happening with a diff is negated. Or does the checkin generate a bit-level patch file on the fly? That would be nice. Mike. On Wed, Sep 26, 2012 at 4:51 AM, David Kean <[email protected]<mailto:[email protected]>> wrote: You checked in the packages folder without the dlls? The dlls are under the packages folder. If you don't want to check in the dlls you can do what's called package restore, which pulls down the packages dynamically, however, a change in the later version means that each developer box needs to opt into this, so it's a lot easier to check the entire packages folder. When you update packages, NuGet automatically removes older versions if no one is using them. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Stephen Price Sent: Tuesday, September 25, 2012 6:12 AM To: ozDotNet Subject: NuGet question Hey all, Just started playing about with NuGet, and checked in the packages folder into TFS. Did a get latest on my other machine and thought that NuGet would toddle off and get the latest dll's that it was missing (Didn't check in the dlls). Have I misunderstood something about what it does? Or am I trying to make it do something it ought not? Is there a trick to make NuGet work with source control? cheers, Stephen -- Meski http://courteous.ly/aAOZcv "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
