+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 >
