Effective Thoughts

Coming out of my post on locking down merges , Tim Wingfield provided the following intriguing inquiry (paraphrased): First, most of our clients don't delve into what our dev practices are, what source control we use, how we use it, or any of the specifics below feature/deliverable level. Am I being sheltered from a bigger problem out there? Secondly, how can we as developers alleviate that issue? Source control, like the language something is written in, really shouldn't matter beyond that of a maintenance issue. A competent dev team is going to make use of all tools available. Removing merging from that list is like telling us to develop in Notepad! These are great questions. First off, if your team is developing a product or a deliverable but not source, I feel the process and tools your team is using shouldn't be of much concern to the client. We should be leveraging 100% of our best practices and the optimal tools to deliver high quality software in th...

Some of the brilliance of MSBuild includes recognizing when source files have not changed and therefore avoiding a re-compile. However, despite possessing an OutDir property, MSBuild always uses the /obj/Debug (or /obj/Release) directory to perform the comparison. MSBuild uses this directory as a temporary folder to avoid contention issues. In our case, our compiled DLLs reside in a separate directory named /build. Thus, with MSBuild writing DLLs into the /obj/Debug directory, it would always rebuild the DLL (thinking it didn't even exist). These "modified" DLLs would be checked into source erroneously. To overcome this, I interrogated the Microsoft.Common.targets file to see what the MSBuild team was doing. (This file sits in [Windows]\Microsoft.NET\Framework\v2.0.50727) To truly override the output directory, I'm using the IntermediateOutputPath and BaseIntermediateOutputPath properties. My MSBuild looks something like this:

I'm excited to be named to TeamFB for FinalBuilder! This is similar to Microsoft's MVP program. I suppose I bugged them with enough questions they figured, "Give him some work to do". Anyway, I think this is a great product and look forward to helping other developers implement this technology.

My latest project involves creating an automated build solution for .Net 2.0 source code. For the solution, we're using MSBuild, Cruise Control.Net, and a commercial product called FinalBuilder . I'll write up a later post outlining the approach/solution but I just wanted to recommend FinalBuilder. It's a great build orchestration solution both on the desktop and the server. It also integrates with CruiseControl.Net, extends via Java/VBScript, COM components, or .Net assemblies (called Custom Actions), and their support rocks. I've been active on their newsgroups while constructing my client's solution. My FinalBuilder posts .