I had this discussion with someone recently and it’s really gotten me to thinking. There is a reason that I don't use that term much to describe myself ... it is so undefined, overused and inappropriately used that, in many ways, it has lost much of its value as a title (to me at least). I cannot even begin to count how many folks I've come across that promote themselves as architects but that I certainly wouldn't call an architect. For some, it's because they don't have any technical depth but are really good at regurgitating marketing material and BS. And because they have no technical depth, they often come up with "architectures" that are very difficult to implement properly because they have no idea what it takes to actually make it happen in the real world. Unless, of course, you write marketing material. For others, they are good coders and, perhaps, could be considered a solution architect (or lead developer) ... but they don't have the vision to see outside of a narrow problem or the short term. For still others, it's a political play in the rough and tumble world of corporate politics. Finally, you have those that are super-smart and in love with building things as complex as possible, using (what they perceive to be) all the latest and greatest tools and toys. If there is a technology that they want to play with, they will make it fit into the project, regardless of whether it actually adds any real value.

Yes, there are some that I would truly consider software architects. They are a rare breed ... they have deep technical knowledge and skills; they can code in the trenches with some of the best developers. But they have something more. First, they understand deeply business priorities and can weight technology choices to meet those business priorities. It's often very hard to get developers to understand this and vocalize it; it was a challenge anytime I did an Architectural Design Session. Yes, they will look at the latest and greatest ... but only adopt it when it actually makes business sense to do so. They also understand that you need to balance priorities and have to make certain trade-offs based on those priorities - for example, sacrificing a little performance in return for higher productivity and quicker turn-around time. Or the other way; it depends on the business priorities. For example, the guys that build Dell.com have very different priorities than the guys that do internal web apps and they will (well, should) make different decisions based on those priorities. Second, they have a "Big Picture" view. They know how the different moving pieces of any even moderately complex software system (should) fit together. I remember once, at an internal Microsoft training event on software architecture, a talk by the original architect of Microsoft Transaction Server (MTS) - which has morphed into different names over the years but is still a core part of Windows. He said that architecture is all about "HST" ... "hooking shit together". In the software world, it very much is. Third, they take the long-term, practical view of development ... not just what we need to do today, but where we are going tomorrow. This is always in flux, but it is a core piece of how they look at the world. Finally, they are also pragmatic ... what can be done within the constraints that we have and with the resources that we have? They know that all things are possible, given enough time, money and resources. It may take building a new operating system or web server or middleware piece from the ground up, but it would be possible. Just not very pragmatic. Unless, of course, that happens to be your business.

I have met folks that meet the above description but there are very, very few of them. I've met far more that fit into the first paragraph. And no, I will not name any names.

In my previous post, I talked about how to debug a TFS 2008 Build using MSBuild Sidekick. But there’s more to this story … you can also do end-to-end (as in, as part of a complete TF Build) debugging of custom tasks. Regardless of the number of unit tests that you write (and they should be numerous), they don’t always show quirks in the environment that you are working in. They do, however, give you a pretty good idea of whether or not your task will work so don’t think that I’m saying that they aren’t valuable. And, of course, based on the end-to-end debugging and any bugs you may find in there, you’ll write additional unit tests to handle those scenarios.

Back to the matter at hand. It’s actually pretty easy once you have MSBuild Sidekick debugging a Team Build. Add your task into the build and call it in one of the TFBuild extensibility targets (preferably in the target that you are actually likely to use). From there, go back to Visual Studio and attach to the MSBuild Sidekick process (Debug … Attach to Process).

And once you are attached, start debugging the build with Sidekick. You’ll go straight from stepping through your targets and tasks into your code and then back again. Very nice!

If nothing else, this is one of the coolest things in TFS 2010. But I am not, unfortunately, afforded the luxury at this time of working with TFS 2010 in my current gig. Though I won’t complain too loudly as it is 2008 and not 2005.

I’m currently working on the build process. As simple as that may sound (and some builds are simple), I do have some pretty high goals. Let me explain. The Team Project is a collection of solutions and projects that are certainly related and tied together in a single software project, but there are 10-15 of them. We have, in Source Control, branches for each release environment and thus, will need to have builds for each environment as well. My ideal scenario would be to pass the environment into TFS Build as a command line argument and have it pull the project from the correct branch, label the project from the correct branch and then create the drop directory with the correct name from the correct branch. And then zip it as well, but that getting that to have the correct branch/environment name is pretty easy as it’s a task that I’m adding in, not changing the behavior of Team Build.

While there is a build debugger in TFS 2010, such a beastie does not come out-of-the-box with TFS. There is, however, MSBuild Sidekick out there that lets you edit and debug MSBuild projects. Since TFS Build projects are MSBuild projects, I figured that this would be a good place to start. So I downloaded the trial with high hopes. I started with simply opening the MSBuild project that TF Build creates when you kick off a build. You’ll find this in the BuildType folder that’s right under the working directory for the Build Agent. It defaults to the Temp folder, but I like to put it in it’s own spot. On the Build Server that I’m working on, it’s F:\Build so you will find your TFSBuild.proj file in F:\Build\BuildType. Simple enough, right? No. When you fire up the debugger, it starts with CanonicalizePaths, then BeforeCompile and then CallCompile. And there it fails.

Digging in a bit, you’ll see a second file in the folder with TFSBuild.proj – TFSBuild.rsp. Hmmm … interesting. Upon opening that up in Notepad, you’ll find a list of stuff that looks remarkably like a series of command-line switches. Guess what? That’s exactly what they are. These are all of the command-line arguments that are passed into MSBuild when the build is kicked off. There are a slew of properties, some loggers and a couple of other things – like the initial target for the build. That’s a little important. Next step – add these into MSBuild Sidekick. You do this in the Properties screen for the build project. First, under project properties, you need to add in ALL of the properties that TFBuild is passing in. Then you have to specify the initial target for MSBuild. They’ll look like this:

When you run it now, it hits CanonicalizePaths and then jumps right to the end and happily informs you that “Build succeeded”. Oh boy. What’s up with this? As it turns out, the first target in the chain for TF Build is “CheckSettingsForEndToEndIteration”. There’s a condition on this - $(IsDesktopBuild)'!='true'. So, let’s now add a property to the command line in our build options: IsDesktopBuild with a value of False. And … here we go again. We get past “CheckSettingsForEndToEndIteration” and go into the “InitializeBuildProperties” target, which calls the GetBuildProperties task. Which then promptly fails with the message:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(267,5): error MSB4018: The "GetBuildProperties" task failed unexpectedly.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(267,5): error MSB4018: Microsoft.TeamFoundation.Build.Client.BuildNotFoundForUriException: TF214007: No build was found with the URI vstfs:///Build/Build/34. Either the URI does not exist, or TFSTEST\Administrator does not have permission to access it.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(267,5): error MSB4018:    at Microsoft.TeamFoundation.Build.Client.BuildServer.GetBuild(Uri buildUri, String[] informationTypes, QueryOptions queryOptions)
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(267,5): error MSB4018:    at Microsoft.TeamFoundation.Build.Tasks.Task.get_BuildDetail()
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(267,5): error MSB4018:    at Microsoft.TeamFoundation.Build.Tasks.GetBuildProperties.get_BuildAgentName()
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(271,15): error MSB4028: The "GetBuildProperties" task's outputs could not be retrieved from the "BuildAgentName" parameter. TF214007: No build was found with the URI vstfs:///Build/Build/34. Either the URI does not exist, or TFSTEST\Administrator does not have permission to access it.

And that, my friends, is where I am now. BUT … at least MSBuild Sidekick allowed be to look at all of the properties as they are when it starts up. And it’s also shown me what the entire process is that TF Build actually goes through. I haven’t done much editing with MSBuild Sidekick (yet) but the debugging … even if I cannot get TFBuild to cooperate fully … is priceless.

UPDATE:

I’ve gotten it working from beginning to end, soup to nuts. :-) Here’s what I did: First, I logged in as the user that the Build Server runs under (don’t lecture me about security; it’s a test environment). I did this because I remember seeing an error message when I tried to change the Build Server’s account about access to some URL or another (I don’t remember the details … I just switched back to the previous account). That still didn’t work. Therefore, I knew that it wasn’t security permissions; that account would need those permissions of Team Foundation Build was going to work at all. So now I’m looking at “No Build Found”. Time to fire up Sql Server Management Studio to see what’s in the TfsBuild database. When I opened up the tbl_Build table (what’s with the “tbl” prefix??? That’s sooo pre-Y2K!), I noticed that there was no build number 34 (look at the URI … it’s in there). BUT … there was a 33 and a 35. Changing the BuildUri property in the BuildOptions (above) did the trick and I was happily stepping through the entire TFS Build process.