Last week I posted up on how we had figured out a way of building .NET 2.0 code developed in Visual Studio 2008 under Team Build 2005 (a component of Team Foundation Server 2005). That post received quite a bit of traffic but like a lot of people I was disappointed that I couldn’t get build .NET 3.5 code, especially since some of our own internal users were asking questions about it.
This week I asked Grant Holliday to prepare a custom .NET 3.5 build server and plug it into Readify‘s own TFS Now instance. My mission was clear – get our own internal .NET 3.5 projects building on top of the TFS Now infrastructure using Visual Studio 2008, Team Build 2005 and a cup of coffee.
I’m pleased to say that we managed to get to the bottom of this one with a fairly satisfactory solution. One of the things that I had to overcome was the fact that Team Build 2005 is hardwired to use the version of MSBuild that shipped with the .NET 2.0 runtime and unfortunately, Visual Studio 2008 projects that target the .NET 3.5 runtime must use the version of MSBuild that ships with the .NET 3.5 runtime.
As I was thinking about the problem I realized that since we already had a working .NET 2.0 build server, I would be able to dedicate this new build server to building .NET 3.5 code, so with a little bit of creative coding (and *.exe file replacement) I could make Team Build 2005 think it was calling MSBuild from .NET 2.0, but in reality, just forward that request to MSBuild from .NET 3.5.
What I needed to do was create a program called MSBuild.exe which I could drop in on top of the .NET 2.0 version of MSBuild that simply took the arguments passed to it and call the .NET 3.5 version of MSBuild. It ended up being about 25 lines of code in a single mainline.
After dropping the executable (MSBuild.exe) compiled from the code into the “C:WINDOWSMicrosoft.NETFrameworkv2.0.50727” directory you will effectively be using .NET 3.5 to do all of your builds. My recommendation is to create a separate build server for this task so that you still have a clean .NET 2.0 build environment.
In the end this ended up being much simpler than I expected, and it seems to work perfecting, including updating the Team Foundation Server 2005 build store. If you have a build server you can use for this purpose you can avoid using the more involved Team Build trick that I posted about earlier.
I’m working from Melbourne next week. I’ve pretty much been on the road non-stop for the last five to six months with usually only a few days at home during the week. Some weeks I never went home and did two weeks straight on the road and stayed somewhere other than my “home-base”.
I have to say that this is something that I’ve been looking forward to for over a month. It was going to be this week (it’s late Friday night here) but for various reasons I had to push it back a week.
During the coming week I’ll be doing on some internal work for TFS Now around getting even greater automation for our customers. My overall plan of atack is going to be:
- Start the day at a cafe so that I can plan my week from a deliverable perspective.
- Work from home for the whole day.
- Work from the “office” for the whole day.
- Find somewhere in the city to work from depending on my bandwidth requirements.
- Probably work from home in the morning and then head into the city for Beer ‘o’ Clock.
Jealous? Well you could always apply for a job at Readify 🙂
When errors occur in applications developers use stack traces to to help them figure out where in the code something went wrong. The stack trace reports the the class and method from which an error originated, and depending on availability of debug symbols which line in the source file each of those class and methods up the call stack are associated.
Sometimes however it can be challenging to find the correct set of source files that were used to compile up the application.
Team Build helps by generating a unique build number whenever it produces a build, and placing all the build outputs into a specific drop folder, but it can be hard to trace back from a single DLL in production to the build number that it came from.
This is where build stamping comes in. Build stamping (not sure if this is what everyone calls it) is a technique where you embed some kind of identifier into the assembly metadata. A lot of people use a standard .NET version string (w.x.y.z) but I prefer to use the build number from Team Build (e.g. TrunkHelloWorld_20070830.5) and put it in something like the assembly description.
The purpose behind this post is to explain one possible way of performing this build stamping using Team Build, MSBuild and the MSBuild Community Tasks.
First, download and install the latest build of the MSBuild Community Tasks mentioned above. This set of libraries and custom build targets. Next you need to add the following code (Import element, and Target element) to the TFSBuild.proj file under the Team Build Type definition.
This will, then, during a build update all the AssemblyInfo.vb (or AssemblyInfo.cs if you change it accordingly) files under the solution root and replace the text “DeveloperUseOnly” in those files with the build number. All you need to do is put that text inside the metadata element where you want the information to appear and bingo – you are now stamping the builds with the Team Build build number.
I’d recommend putting it in the description because it shows up in the list of properties when you right mouse click the file in Windows Explorer.
Whilst I reckon I would stand out like an old shrub in a field full of flowers at an Operator Please concert – I really like their music. Also – check out this song about ping pong 🙂
From what I understand the band originates from the Gold Coast.
A few weeks ago I was doing some work with a client in Sydney helping migrate their existing code base across to Team Foundation Server. One of the developers who also happens to play the build master/release manager role asked me if there was a better way of deploying their software.
Their current approach was copying the files onto a network share and adjusting the security policy of the user workstations to allow that code to execute with full trust. One of the problems that they were running into was that in order to update the program they had to rename all the files before deploying because they were locked by users who were currently using the software.
This was a fairly common approach back in the .NET 1.0/1.1 days, and if you wanted to get around it you had to build some kind of boot strapper that would set up an application domain and shadow copy the files, similar to the way that ASP.NET does to avoid file locking.
Fortunately, in a .NET 2.0+ world Microsoft has made our lives a little bit easier with the introduction of ClickOnce, although not everyone knows of its existence. I told the client about ClickOnce and they went off and did some experimentation.
The following week I visited the client again and I got the obvious question – how do we get ClickOnce working with Team Build?
The good news is that it isn’t that hard as Team Build has built-in support for working with ClickOnce enabled projects. The steps that you need to follow are:
- Enable ClickOnce in your application (you can do this via the properties window, or by doing step two below).
- Do one ClickOnce deployment manually to make sure all the appropriate configuration entries are written to the project file.
- Edit the TFSBuild.proj file and copy the “SolutionToBuild” line, and put it below, and rename it to “SolutionToPublish”. The screen show below provides an example.
Team Build will then build the code and place a versioned ClickOnce directory in the drop folder that you can then copy over to your deployment location. If you are feeling adventurous you could even use TFS Deployer to automate this step.
I feel somewhat sheepish in posting this since I am so late, but I just wanted to point everyone to this post of Greg Low’s where he announces the Readify Developer Network.
Basically we are going to be putting on a number of events where we get members of the Readify team to present on something that they are really passionate about. Hopefully it will grow the pool of people who are willing to attend user groups and other technical community events.
Sometimes life gets too busy to process all the information that is coming into my Inbox or aggregator. Because of this I’m pretty brutal about when I decide to process information. If I receive an e-mail that doesn’t require an action from me then I will often put it into the maybe pile having briefly glanced at its contents.
With blog posts I tend to star them in Google Reader. It is quick (important) and I can come back to it later on. At the moment I’ve got “more than 20 items” in my starred items and I am going through them decide if, now after a week or more has passed I really want to do anything other than un-star it.