You’re preaching to the choir. ☺ We’re always looking at making setup better, unfortunately, it’s extremely hard to do with one of the largest products Microsoft makes. Baby steps; each version (although it may not look like on the outside) installation gets incrementally better on the inside. No more custom actions, yay!.
If you’re interested in helping out, come join us @ https://careers.microsoft.com/. For example, you want to work on the VS project system, try this one: https://careers.microsoft.com/JobDetails.aspx?jid=33185&lang=en. From: [email protected] [mailto:[email protected]] On Behalf Of mike smith Sent: Monday, February 07, 2011 10:13 PM To: ozDotNet Subject: Re: Handling 3rd party assemblies with build servers On Tue, Feb 8, 2011 at 3:48 PM, David Kean <[email protected]<mailto:[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]> [mailto:[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
