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.