This is what happens when developers aren't network guys...

In a previous post, I was confused over which user account TfsBuild.exe executes under. I kept on getting various file exceptions and whatnot.

Well now I know. It runs using the account you specified for all your Team Foundation Server Services to run under (In the installation guides, it's the one called domain/TFSSERVICE). I can't remember if I specified this account at install-time or not. But there you go.

Which brings me to the next thing that was causing trouble recently. I wanted to create a new build type that, as well as compiling my application, published it to our test server as well. Very quickly, it was just a matter of creating a new target in the .proj file called "AfterCompile" (overriding the one in the default .targets file), and adding an AspNetCompiler task to it for each website I wanted pushed up there.

Problem was, the TFS Service account couldn't see the folder I was deploying to. No problem. Browse to that folder in explorer, fire up the properties, grant TFS write access and bob's yer uncle. Right? Wrong.

After a couple of us pored over it for a while my boss' boss casually asked "Have you enabled write access to the share itself?" DOH! Although according to NTFS, the TFS account had write access to that directory, the initial fileshare (about 3 levels up) only had read access enabled. So I could browse to the directory I wanted to in explorer, but writing to it was being blocked by the share permissions.

I didn't know it worked like that. I figured NTFS alone governed the access level to that directory.

And that is what happens when developers aren't network guys.

Just wanted to share.

Something I really could do with finding out...

... But I don't know how.

Here are a couple of things I know:

• Timers aren't thread-safe
• BackgroundWorkers are thread-safe

It's a shady proposition setting a timer running on a form, and doing a straight method call to update the form's display. It works sometimes, but because the timer runs (or at least can run ) on another thread to the rest of the form, it sometimes falls over.

There are a few nice elegant ways of sorting this all out and getting everything running properly in .NET 1.x, but .NET 2.0 brings with it the BackgroundWorker class.

Which is a nice thing, particularly if you want to do some long running processes and update your UI as they go.

This I know.

But what I don't know is: what does the timer do when it's not elapsing? Obviously it's ticking away, just... well... being a timer, but is that it?

What I'm getting at (albeit in a roundabout and thoroughly confused way) is this:

I have a countdown timer that updates the form every second. I can't just use a timer to do it and handle its Elapsed event, but what if I fired up a BackgroundWorker, and then just called System.Threading.Thread.Sleep(1000) in a loop, raising the ReportProgress at each cycle through the loop?

Is that a good idea? It seems to me to be the easiest, certainly the quickest way to achieve it, but is it really good practice? Thread.Sleep() always strikes me as being a bit of a hack, but it works.

I'm sure I'll work something out eventually. Who knows. Could be I'm doing it a good way. Doubt it, though.

Just wanted to share my bafflement. Of course, if anyone knows the answer, then let me know.

Scheduling builds using Team Build

Today I've been having big fun trying to get an automatic build schedule together for the project I'm working on at the moment.

Yes, that's right. Trying. Nearly there, and there are several things I've learnt along the way about Team Build. Here are the important ones (in no particular order):

1) There's no inbuilt scheduler.
No real biggie, but before you spend half the morning looking for it, know that it's not there to be found. You'll just have to schedule it to run via Windows' task scheduler.

2) The command line tool TfsBuild.exe rules
See 1. Actually, I must say, the command line tool is really useful. It lives at:
<TeamBuildInstallDir>\Common7\IDE\TFSBuild.exe and is surprisingly good.
It can be called using:

TfsBuild.exe start <TeamFoundationServer> <ProjectName> <BuildType>

As you might have guessed, it'll go to your TFS Server, find the build type you've specified, download the configuration from source control (the current checked in version) and build based on that. Which I think is really neat.

It's not without its quirks, though. I spent ages feeding it different renditions of our server name (http://server, http://server:8080, etc...) and it kept on saying it couldn't find the server I was pointing it at. I found this post from someone who was having exactly the same problem, though, and the solution at the bottom worked for me. Go into the registry and find HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\Servers and add your server in there. Admittedly, I mimicked exactly what Joey Bradshaw did and put the friendly name of our server in as the key, and the full server name as the value. I don't know if the key is significant, but by this time I was getting hungry and wanted to go to lunch. Worked, though, which is the important thing.

3) Any kludges you've put together for getting your project to compile - better fix them properly
Yes, I know, this is pretty much the whole point of an automated build. But still. I came a cropper a couple of times with dll references.

We have a bunch of 3rd party and legacy dll's that we reference from our current project, which is fine. We keep them on a shared drive, the dll paths in the reference and the .refresh files in websites are pointing to that share, everything's happy. Until...

4) I'm buggered if I can work out what user account TfsBuild.exe runs under.
I kept on getting reports that the drive out shared dll's live on didn't exist. And fair enough, the standard shared drive mapping that all the developers use wasn't there. No biggie. Just log in under the account the Team Build service runs under, map the drive, and Bob's your uncle, yeah? No. Kept on getting the same errors reported that the drive didn't exist.

So I changed all the references in the source code to full network paths. Sorted, eh? No. Changed the permissions on the network share to allow the Team Build Service account read access, and it all worked fine. Go figure. It wouldn't pick up the drive I mapped under its account, but it's definitely the account that goes fishing about on the network to find those pesky dll's.

Oh well. It's done now.

So (at last!) I've got a successful build going on. Yeah?

Almost...

5) Your project may well compile, but your Unit Tests might not...
Once I got my main project to build, I shifted my Test project from the old server to the new. Yeah yeah, I should have done all that when I first moved the rest of the project, but hey, this is me. It was Friday and I just wanted to get everything working and go home.

So I moved my Unit tests over, changed all the external references (as I had discovered already. Built fine. Go to run it? Nope. Unit Tests don't run at all. Compile fine, but won't run. You'll need to give the dll's in the shared folder elevated elevated privileges to get them to run (elevated from the normal Intranet code group, anyway).

6) There's nothing better on this earth than that little green tick!
No matter what people tell you. When you see that green tick, there's nothing better!

7) Once it all works, it Team Build really does rule!
The reports Team Build produces are so cool. They're so comprehensive, and the integration with the rest of Team Foundation Server is fantastic. Once your project builds, it'll go back and See what changes have been checked in since the last successful build. It'll find all the work items associated with those changesets, indicate on them all that those changes have made it into a build, and give you some friendly statistics and scary numbers to tell your boss.

It'll even create a new work item if it fails that links to the failed build report and tells you to fix it!

All in all. It's been a bit of work today, and it's not quite over yet. But we're now running automated nightly builds and loving every second of it!

Just wanted to share.

The Midas Touch

There are some people that just have the touch of gold for some things.

Carl Franklin is one of them.

I've been listening to DotNetRocks for a couple of years now, and it's always been fantastic. In fact, when I'm not talking to my boss, I crdeit my entire career to DNR. Obviously, I tell my boss it's all down to me being fantastic!

But now he's come out with DnrTV.

It does rule. I've seen much love in the blogosphere (although I hate that word!) to prove it.

The only thing I have trouble with is remembering everything. Not only do I have to seclude myself from the missus for an hour, but it is also like a total vulcan mind-meld taking it all in!

BUT. It does rule. It's right there on the top of my list of things to do when Mrs Mawoo is out.

PS - Nobody can ever beat Geoff's hair (nb Geoff is second from the right, the one up from the... well ... you'll spot him from his hair! It's the greatest, I have dreams where my hair is as cool as Geoff's!)

PPS - If anyone wants an MSN 8.0 Beta invite, just email me

PPPS - Did I say right? I Geoff's in fron the left! In fron the right is ActiveNick.