Mike I want that too, so give us a shout when you wrote it. It is a long weekend after all...
(shouldn't be hard to hack up the nuget server quick start demo into a caching proxy, right?) On 26 Sep 2012 14:57, "Michael Minutillo" <michael.minuti...@gmail.com> wrote: > Yeah but I want to transparently set an internal server as my NuGet > repository and if the package is there when requested it is served straight > up. If the package is not there, go get it, cache it and serve it up so > next time we don't need the web. Technically speaking, each time I get a > specific version of a NuGet package it should never change so why rely on > the feed always being up? > > > On Wed, Sep 26, 2012 at 2:40 PM, David Kean <david.k...@microsoft.com>wrote: > >> It’s called a network share. J NuGet supports them.**** >> >> ** ** >> >> *From:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Michael Minutillo >> *Sent:* Tuesday, September 25, 2012 10:37 PM >> >> *To:* ozDotNet >> *Subject:* Re: NuGet question**** >> >> ** ** >> >> 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.**** >> >> **** >> >> I think that we'll be looking into this option as well. It'd be good to >> have a caching NuGet proxy server in our network. Sounds like an open >> source project :)**** >> >> ** ** >> >> On Wed, Sep 26, 2012 at 1:22 PM, David Kean <david.k...@microsoft.com> >> wrote:**** >> >> 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:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *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 < >> step...@perthprojects.com> 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 <meski...@gmail.com> 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 <david.k...@microsoft.com> >> 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:* ozdotnet-boun...@ozdotnet.com [mailto: >> ozdotnet-boun...@ozdotnet.com] *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**** >> >> **** >> >> **** >> >> **** >> >> ** ** >> > >
