Clark Sell : TeamBuild

Blogging again????

csell — Fri, 22 May 2009 17:02:10 GMT

You know sometimes it’s just sad how fast time can go by. Looking back it’s been well over a year maybe two since I last blogged. WOW, that’s not cool. So what the hell happened, well LIFE I guess. Let’s see:

I had my second child ( girl, Addison ). We are blessed to have one of each and both healthy.
I got to meet Bill Gates, Steve Ballmer and all of the rest of the Microsoft executives
Bought a Honda ( needed a 4 door with 2 kids )
This fiscal year I will have billed over 2300 hours which doesn’t account for my other job. Can you say Year of the Death March!!!
Ran into Sieg from the Deadliest Catch at SeaTac
Learned how to make the perfect Margarita!

Regardless a lot has happened and it’s time to talk technology again. I love it and really miss doing it. With all of the great stuff here upon us now, it’s time to start sharing. I was reading MSDN Magazine the other day when I ran across an article about MSBuild and best practices which really got me thinking. There were two items that really stuck out for me:

Compilation of large source trees. I think it’s a must read but caution readers that “large” can mean many different things.
Reference Management

While both were explained pretty well, lets put #2 into practice. *I’M LAZY* ( in a good way of course ). I would much rather write something once rather than screw with it time and time again, especially the stuff you have to do like build work.

So lets talk assembly references….

Assembly references can be easy as you want it to be but sometimes a little prep work will go a long way. The .NET compilers and runtime both have a specific order in which they look for references. If you look in your framework folder for Microsoft.Common.Targets you will find the following:

The SearchPaths property is set to find assemblies in the following order:

Files from current project - indicated by {CandidateAssemblyFiles}

$(ReferencePath) - the reference path property, which comes from the .USER file.

The hintpath from the referenced item itself, indicated by {HintPathFromItem}.

The directory of MSBuild's "target" runtime from GetFrameworkPath. The "target" runtime folder is the folder of the runtime that MSBuild is a part of.

Registered assembly folders, indicated by {Registry:*,*,*}

Legacy registered assembly folders, indicated by {AssemblyFolders}

Look in the application's output folder (like bin\debug)

Resolve to the GAC.

Treat the reference's Include as if it were a real file name.

So what if your not one of those nine?!?!?

Since it’s all just angle brackets we can extend the “out of the box” search paths. As it was explained in the article you can override the property AssemblySearchPaths. Aaron had a great post on MSBuild Property Evaluation, it’s something you should read. Overriding a property is as simple as importing your own target file into the stack and then resetting the property ( for most cases ). You could also just add a the same property further down the stack in the same file. Both are essentially the same. With MSBuild the *stack is always important*. If you were to import your target file or override a property to early you might change the way the entire build system works. There are a number of properties that work like:

<AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''">

This is a very common practice throughout MSBuild implementations. As you can tell it’s just a way or protecting yourself from a change in behavior upstream. Remember MSBuild parses top down to you have no influence what might be done afterwards. In our case what we want to do is import our targets file after the Microsoft.Common.Targets file in the csproj or vbproj file(s).

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

<Import Project="..\MyTargets.targets" /> *NEW*

By doing so AssemblySearchPaths will be “” and initialize itself as expected. So if we want to add to it it’s as simple as ( snip from MyTargets.Targets ):

....
    <PropertyGroup>

      <AssemblySearchPaths>
          $(AssemblySearchPaths);
          C:\binaries\;
      </AssemblySearchPaths>
    </PropertyGroup>
....

Define a Property Group
Define the Property ( AssemblySearchPaths )
Set it to itself and add to itself

Important point, Reference Paths are folders not files. So now if you compile from the cmd line or from VS you will have your paths in the stack. The easiest way to see what is going in is to simply run msbuild.exe /t:rebuild /v:diag on your sln file. That will dump everything that took place during the execution from MSBuild. Even the order of folders it searched for. You will actually be able to see the reference pats listed that it couldn't find.

But we are not done yet. We have a hardcoded path and remember, I’m lazy. How about we bootstrap ourselves into the build process and read the file system building the search paths based on a “root” folder you specify? Then any machine should work without any change.

<Project InitialTargets="bootstrap" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

    <PropertyGroup>
        <referencePath>$(SolutionDir)..\MyBinaries\**\*.*</referencePath>
    </PropertyGroup>

    <Target Name="bootstrap">
   
    <CreateItem Include ="$(referencePath)">
      <Output ItemName="binariesFound" TaskParameter="Include"/>
    </CreateItem>
    
    </Target>

  <PropertyGroup>
      <AssemblySearchPaths>
        $(AssemblySearchPaths);
        @(binariesFound->'%(RootDir)%(Directory)');        
      </AssemblySearchPaths>
    </PropertyGroup>
  
</Project>

Important points:

InitialTargets was set. This gives us the ability to run *first*. Why? Well we want to read the file system and build the list of folders.
We create an item during the execution of the target rather than statically.
We later transform that target just adding the folder rather than the whole file path.

Team Build has a similar concept but much easier. At the bottom of any tfsbuild.proj fiile there is a commented collection called AdditionalReferencePath. It works the same it’s just that the Team Build process does it all for you already.

Microsoft.TeamFoundation.Build.targets ( 2005 )

csell — Fri, 21 Sep 2007 16:41:16 GMT

Have you ever wanted to *see* the target stack in the TeamBuild targets? Well the wait is over. I wish I could say I generated this on the fly but that isn't the case, but one day that will happen. I intend to keep growing this map as I come across new items and documentation. If you would like a copy feel free to reach out.

Click on the image below for a larger clickable map.

Build Status TFS Policy, Part II

csell — Fri, 27 Oct 2006 20:56:00 GMT

Since my post yesterday I just decided to update the code and also include Buck's comments. I even added a simple installer as a bonus since that last post was just useless. Here is the new version and this time in a zip ;)

Stop, the build is broken!!

csell — Thu, 26 Oct 2006 17:24:09 GMT

It's late, your tired and yet somehow you got stuck fixing the build because junior engineer bob just fired off a check-in and took off. It looks like the build is now broken because junior hasn't done a get latest in a month. In the meantime 10 other people check-in and just end up compounding the problem.

Unfortunately things like this happen. One day I just got so frustrated, I just wrote a custom TFS check-in policy which gets the last build status and validates a particular build type was actually passing before you check-in. I started with Jeff Atwood and James Manning posts where they have done a great job explaining how to write a simple custom check-in policies.

UPDATE:: I have since updated the policy to include a few fixes and packaged it up into an MSI and Source. You can download that here:

http://blogs.msdn.com/csell/archive/2006/10/27/build-status-tfs-policy-part-ii.aspx

Microsoft.SDC.Tasks, New Version Released

csell — Wed, 12 Jul 2006 16:32:38 GMT

If you are doing anything with .Net 2.0 chances are you have a set of MSBuild files supporting your application. That means you already know MSBuild just rocks. What better than MSBuild? MSBuild with a sweet task library to support it of course! That task library would be the Enterprise Solutions Build Framework or Microsoft.SDC.Tasks as I like to call it.

Well they just released a new version! The biggest change was the introduction of BizTalk 2006 tasks. If BizTalk isn't your fancy then you will be pleased to also know there are some new TFS tasks also.

To find out more information visit http://www.gotdotnet.com/codegallery/codegallery.aspx?id=b4d6499f-0020-4771-a305-c156498db75e

These guys do a stellar job! I have been using this library for about a year now and it goes everywhere I go.

The Build Master

csell — Thu, 08 Jun 2006 17:07:02 GMT

I don't think anyone will argue but the majority of technical books are used for reference. OK so every so often a new book comes out and you read it cover to cover. Well that time has come.

Vincent Maraia has just authored a book called The Build Master. If you have anything to do with software development then you MUST read this book. I don't care how good you are, how many products you shipped or if you are already a build master, you MUST read this book.

Every development shop must address most if not all of the topics found in this book. If you're not, then you really need to invest some time and money in yourself and clean shop. I guarantee things could be better. Just ask yourself a few questions:

Do you have a good concurrent development mailline strategy? Do you know what one is?
Do you know how to branch and merge?
Do you version?
Do you have any automation?
Do you have a build process?
Do you have a build team?

If you have answered No to any of these questions then just go buy it now and start reading. Again regardless no matter who you are, you still need to read this book.

Vincent Maraia, Great Read and Great Job!!! I can't wait for the next one.

Table of Contents

Defining a Build
Source Tree Configuration
Daily Not Nightly Builds
The Build Lab
Build Tools
SNAP Builds
The Build Environment
Visioning
Build Security
Managed Code Versus Unmanaged Code Builds
Building for International
Build Verification Tests
Building Setup and Deploying Every Day
Ship It
Product Support Services
Hotfixes or Patch Management
Suggested Steps to Change Your Religion or Philosophy (Corporate Culture)
Future Build Tools from Microsoft