Have you been getting an intermittent error similar to the following during a TFS Team Build execution (within the CoreGet target) ?:

Access to the path 'C:\Documents and Settings\tfsbuild\Local Settings\Temp\TFSTemp\4580{#$@;._}808' is denied.

If you look around, you will find a few folks who point at antivirus software as the culprit, but in our case it turned out to be the disk defragmentation service…

Team Foundation Server 2008 provides the ability to specify a “remote” Sql Server Analysis server as well as a remote Sql Server Reporting server.  Normally, your Analysis Server is located with the data tier, and the Reporting Server is located on the application tier.  (Of course, everything can be collapsed on a single physical tier as well.)

However, by editing the “msiproperty.ini” file within the “AT” directory of your installation media, you can customize this.  The relevant keys are VSTF_RS_SERVER (reporting) and VSTF_AS_INSTANCE (analysis).  See the Team Foundation 2008 installation guide for details.

What you should know, however, is that apparently Reporting Server instances are not really supported.  If you attempt to specify an instance name in the VSTF_RS_SERVER property, the installation will fail.  This property needs to refer to a server name only.  TFS 2008 apparently expects the instance name to match the data tier instance name (a strange assumption.)  If that doesn’t work, it tries the default instance.  (After that, it will try the first instance it finds…so you might see “WARNING: Selecting the first instance name of…” in the installation log.)

According to this, you won’t see a change in this behavior with TFS 2008 SP1…

I have a few clients that would like to see TFS make use of an enterprise Reporting Services infrastructure (rather than spinning up a new reporting server…)  If you do as well, this is something to keep in mind.

Update: Slides from the talk we gave are available here.

I’ll be doing a talk with Geof Lory about Team Foundation Server and Application Lifecycle Management (ALM) at TechFuse this coming Tuesday (February 26^th, 2008)…

Looks like a great event all in all for those in the Twin Cities!

TFS Deployer is a great tool that allows you to automate application deployments.  It does so by acting as a service that listens for “Build Quality” change events dispatched by TFS – and then kicking off a PowerShell script that is appropriate for the server and the build type.

I’ve had very good luck making use of TFS Deployer with a few clients to facilitate unattended deployments of BizTalk applications.  I’ll have more to say about the “BizTalk” piece of that in coming months, in collaboration with my good colleague Dave Comfort.  Suffice to say that if you’re using the Deployment Framework – but would like a one-click solution for deploying to multi-server environments, you will want to watch this space.

In the mean time, if you are making use of TFS Deployer already, you might find it helpful to share some slightly more formal documentation with your operations staff, etc.  You can certainly glean what you need to from here and here, but I believe you’ll find this consolidated resource a help.

(p.s. – keep an eye on the future of the TFS Deployer project here.)

I’ve had a few folks ask recently about the presentation I did for MDC 2007 on release management and branching strategies with Team Foundation Server.  The PDF was available on the conference site, but not the PowerPoint, so here it is.

I was working with a shop recently that wanted to be able to do very fine-grained deployments (of a web application) into production.  They were pretty far into their Team Foundation Server adoption, and wanted to be able to deploy the files contained in the changeset(s) that were tied to a particular work item. 

So, for instance, to close a particular bug work item, three changesets might be checked in (each associated with that work item.)  Each of these changesets might comprise multiple files.  When preparing to stage the fix, the client wanted to simply say “go get work item 1237” and have the right thing happen (i.e. all files retrieved, preserving folder structure) – even without a workspace defined.

They were happy to let me share the solution with you, so you can download it here.  You’ll have to build it yourself, pointing at the correct TFS assemblies.

It is a command line utility – the command line help is as follows:

GetCSForWI v1.0.0.0
Copyright 2007

Retrieves files associated with changesets or changesets
that have been associated with a particular work item.

Usage: GetCSForWI.exe [@argfile] <tfsServer> [/changeset:<changesetNumber>]
       [/workitem:<workitemNumber>] [/path:<localFolder>] [/help|?|h] [/version|v]


@argfile                      Read arguments from a file.
tfsServer                     TFS Server name
/changeset <changesetNumber>  Changeset number to retrieve
/workitem <workitemNumber>    Workitem number to retrieve changesets for
/path <localFolder>           Local folder to copy to (after getting to
                              workspace)
/help                         Show usage.
/version                      Show version.

A few folks have discussed the topic of building BizTalk solutions with TFS, namely here and here.  As most have surmised in the time since TFS originally shipped, you have to build BizTalk solutions with “devenv.exe” if you are going to use Team Build, by overriding the “AfterCompile” target.  This is because there is no “standalone” xlang compiler (at least not that you & I can use) – it instead loads in-process to the IDE.

Your steps will be something like the following:

• Do a “developer tools only” install of BizTalk on your build server.  No need to install the BizTalk services or databases, etc. (unless you intend to deploy & run post-deployment tests on the build machine.)  Note that since you need to install Team System Dev or Test to run post-build unit tests anyway, you aren’t really installing that many more “bits” on your build server (if you are skipping the BizTalk runtime/database infrastructure.)
• Comment out the line in your TFSBuild.proj file that looks like this: <SolutionToBuild Include="$(SolutionRoot)\path\MySolution.sln" />
• Create an AfterCompile target that looks something like this:

What isn’t immediately obvious is that if you want to execute unit tests as part of your build process (i.e. tests that don’t require your BizTalk solution to be deployed…think build verification) then the DevEnv method of building can cause you trouble.  The testing portion of the build process expects your binaries to land in the “Binaries” folder — a peer of Sources, BuildType, and TestResults in your build location.

Therefore…you will want to add something like this at the end of your AfterCompile target:

With this in place, the unit testing portion of the build process can execute as if you hadn’t resorted to calling devenv.exe…

Update: Are you getting an error like this: “The specified configuration and platform ('Debug/Any CPU') is not defined.” — right at the point that test results are supposed to be published?  I don’t entirely understand this, except to say that something in the core TFS targets is apparently responsible for populating the Platform_Flavors table in the TfsBuild database.  This step might not happen if you take over compiling by calling devenv.exe.  Take a look in that table to see if the platform/flavor you are trying to use is listed there…

Update: I realized shortly after I posted this that theTfsVersion task reports the latest changeset present in a particular location within the build server’s workspace…not on the server.  Rather than re-write the task to interrogate the server, my short-term approach is to set up the (msbuild) call to my custom task like this – notice the “Get” ahead of TfsVersion that ensures we are looking at an up-to-date changeset number…rather than the one present in the workspace by virtue of the last build.

—

If you feel the need to customize your TFS Team Build number, it appears there are some (non-obvious) rules for doing so.  I wanted to add the latest changeset number (scoped to the branch I was building) on to the end of the build number as a suffix.  I’m using a combination of the TfsVersion task from the MSBuild Community Tasks and a custom task called within BuildNumberOverrideTarget.

My first cut was to simply take the default generated build number (like Dev_20071231.4) and add an underscore followed by the changeset number.  Like, say, Dev_20071231.4_335.  This works…exactly once.  After that you get the following error message:

TF42054: Team Foundation could not start the build. Please check the event log on the build machine for additional information.

None of the tracing flags for MSBuild seem to shed any light.  Your build type is basically toast, until you delete the build (and change your build number customization logic.)  Then I discovered that this was, at least to some degree, a known issue.  What I don’t think is so well understood is that even if you take complete control of your build number generation, you really want to leave an incrementing number at the end of the build number so that:

1. You can guarantee uniqueness even when every other component of the build number remains the same – since Team Build requires this.
2. To accomodate the fact that before you get a chance to customize the build number, Team Build runs parsing logic on the last build to try to determine what the new (default) build number should be.  If this parsing logic fails, you’ll get the above error. 

Ultimately I wound up generating something like this: Dev_1.0_20071231.44.2.  It has these components:

• Build type
• Release “friendly name” (any string)
• Date stamp
• Latest changeset number for the branch
• Incrementing number

I borrowed from the sample here, and wound up with this.  I’ll write more shortly about whether there are any behavior differences to be aware of in TFS 2008.