Ok, so I'm not doing anything out of the ordinary. Looks like it is only tools like DevExpress that REQUIRE that you install it onto the build server that messes things up.
-David Burela On 8 February 2011 21:05, Stephen Price <step...@littlevoices.com> wrote: > +1 for a Third party/dependencies folder. Here its called Lib. I've > used Dependencies in the past. Its good to have everyone using the > same version. > > I had an issue with a fresh get of the solution yesterday and it > turned out the reference was pointing at the release folder of a > solution. The devs who had built Release previously didn't notice all > the broken references. It's also great for getting a solution up and > running without installing 20+ different third party packages. You > shouldn't need to install any! > > I've really only seen all of the dll's in one folder too, but I can > see some merit to subfolders for each separate third party. Some of > them have lots of weirdly named dll's and it would help organise them. > > On Tue, Feb 8, 2011 at 4:51 PM, Tony McGee <tmc...@pacific.net.au> wrote: > > Interesting, our dev team was talking about this issue just today. > > In our team we check in any 3rd party assemblies into a folder like > you've > > done. If an assembly is downloadable in source form we do a compilation > and > > then the source goes with the pre-built assembly and generally works > pretty > > well. > > > > One of the other devs mentioned difficulty with the DevExpress components > > not installed on the build server and causing issues with building if the > > bundle wasn't installed there. We should probably talk to the vendor, but > it > > was quicker to just perform the install even if it feels dirty to make a > > dependency on any part of machine config other than vanilla Visual > Studio. > > I'm interested if anyone has solved this issue as well! > > > > Tony > > > > > > On 8/02/2011 2:09 PM, David Burela wrote: > > > > For the last few years I've used a fairly standard way of handling 3rd > party > > assemblies. > > In source control, I create a folder called "3rd Party Assemblies" which > is > > where I put all the external references (like nSubstitues, Ninject, > etc.). > > > > /DavidSolution > > DavidSolution.sln > > /3rdPartyAssemblies > > /nSubstitue > > /Ninject > > /... > > /Project1 > > /Project 2 > > /... > > > > It works well, learnt it from Mitch years ago. However something that has > > always tripped me up, is how do you handle assembiles that are installed > on > > the computer? > > Here I am thinking of Telerik, Component art, DevExpress, and most other > > purchased libraries. > > At the moment I am using Telerik, you need to install it onto your > machine > > and it puts the license file somewhere. > > We have a number of devs working on the same project, so we all install > the > > tools on. > > Now when it comes to building, i'll need to install the tools into the > build > > server. Whenever a new version comes out, i'll need to get everyone to > > update the computers and if they forget, then people are out of sync, or > > they could be working on 3 different projects and their other projects > may > > not be upgraded yet. > > If I copy all the Telerik controls that I need into the 3rd Party > Assembly > > folder, then when I upgrade my version of Telerik I can just copy the new > > .dlls into the 3rd party assembly folder, and all other devs will > > automatically pull down those .dlls with a get latest. and hopefully the > > build server will work with them just in the 3rd party assembly folder, > but > > there might be a license issue? > > Putting the .dlls into the 3rd party assembiles folder seems like a good > > idea to make sure that the project is on a specific version of the tools. > > BUT then you lose some other features like having Telerik automatic > > migration your solution references to the latest version of the > assemblies. > > > > > > So to sum up my question: > > With the libraries that you need to install (Telerik, Component Art, > > DevExpress). How do you guys handle the assembly references? Include in > > source control, install the framework on EVERY computer? or some other > > solution? > > -David Burela > > >
