On Wed, Sep 26, 2012 at 3:03 PM, Michael Minutillo < [email protected]> wrote:
> 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. > > Something like a mirror? The internet connection going down fails the build anyway, for us. (remote SVN, signing timestamps) > 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". > > Space is cheap, bandwidth is still not fast. If it's all on a 1G lan, that's fine. > > Michael M. Minutillo > Indiscriminate Information Sponge > http://codermike.com > > > > On Wed, Sep 26, 2012 at 12:52 PM, Stephen Price <[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]> 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]>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]] *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 >>> >>> >> > -- 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
