On Tue, Feb 8, 2011 at 3:48 PM, David Kean <[email protected]> wrote:
> Now I’m from Microsoft, so bear in mind that we tend to over engineer > solutions, however, we typically make sure *everything* is in source > control. (In the Developer Division case, this even extends to.NET [and > VS!], but completely ignore that part) > > > > In any shop above a few developers I would personally put anything that > doesn’t come with a standard VS installation, including build scripts (even > build targets such as Silverlight v4.0 targets) and any 2nd/3rd party > references. This makes ensures that the Devs and the build machines are > always building *exactly* the same thing – unfortunately, in certain > situations MSBuild will pull references from the GAC if it can’t find them > anywhere else, with can lead to issues such as devs compiling against some > fandangled new version installed on their box, instead of the one they > should be compiling against. > > > > This also has the advantage of making it easier for new devs, because all > you need to tell them to install VS and do a full *get* of the database. > > If only VS did xcopy deployment, you could tell them just to do a full get. Some quite complex setups do work with xcopy, so how about it? > > > With regards to the automigration thing with Telerik, wouldn’t this happen > automatically when you checked in and overwrote the new binaries? > > > > > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *David Burela > *Sent:* Monday, February 07, 2011 8:09 PM > *To:* ozDotNet > *Subject:* Handling 3rd party assemblies with build servers > > > > 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 > -- Meski "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
