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.)

“Error creating UDDI entries... Error 285023” – are you getting this while attempting to get the ESB Guidance up and running? 

If your event log has an entry containing “UDDI_ERROR_AUTHTOKENREQUIRED_NOTOKENPUBLISHATTEMPT” chances are you have anonymous authentication enabled for your UDDI virtual directory.  Turn it off, and try again.  If this isn’t the issue (or you are having other UDDI issues while installing the ESB Guidance) try cranking up logging to “verbose” for the UDDI service itself.  (See Administrative tools, UDDI Services, properties on your machine.)  There is generally enough context in there to troubleshoot…

 

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:

  <Target Name="AfterCompile">
 
  <!--Call DevEnv to build the BizTalk Solution-->
  <Exec Command="&quot;C:\%programfiles%\Microsoft Visual Studio 8\Common7\IDE\devenv&quot; &quot;$(SolutionRoot)\BizTalk\Dev\MyBizTalk.sln&quot; /Build &quot;$(BuildFlavor)|$(BuildPlatform)&quot;"/>

  <!-- Create a drop location -- >
  <MakeDir
   Directories="$(DropLocation)\$(BuildNumber)\$(BuildFlavor)"
   Condition="!Exists('$(BinariesRoot)\$(BuildFlavor)')" />

    <!-- Do whatever work you would like here - assemble binaries, build an MSI via WiX, etc. and
         place the outputs in the drop location. -->

 </Target>

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:

    <!-- Get our build outputs into the "binaries" folder to facilitate unit testing. -->
    <MakeDir Directories="$(OutDir)"/>
    <CreateItem Include="$(SolutionRoot)\**\*.dll" >
      <Output ItemName="FilesToCopy" TaskParameter="Include" />
    </CreateItem>
    <Copy
          SourceFiles="@(FilesToCopy)"
          DestinationFolder="$(OutDir)"
          ContinueOnError="true" />

 

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…

I believe there is a problem with the "pre-converted" (from MOM 2005) management pack that is offered for BizTalk 2006 on the SCOM 2007 management pack download page.

I believe the conversion started with the BizTalk 2006 (flat) MOM 2005 management pack, rather than the BizTalk 2006 R2 version.  The latter is available here.

Assuming you have already installed the MOM 2005 Backward Compatibility Management Pack, version 6.0.5000.12, you should be able to import the 2006 R2 version (via the Operations Manager Migration Wizard.)

The reason this is important is because the computer attribute that the (older) management pack is looking for includes:

MatchWildcard(AttributeValue(BizTalkServer2006Attribute), "3.5.*")

BizTalk 2006 R2 has a version stamp of 3.6.1404.0.

(I believe other folks have run into this issue as well.)

Update: Because the import/conversion process is a bit of a hassle, I thought I’d post the SCOM-converted files here for download.  These were produced by starting with the R2 AKM files, converting to xml via mp2xml.exe (in the MOM 2005 resource kit), and then finally apply MPConvert.exe from the SCOM tools.

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.

My article on a custom method for orchestration-based throttling appeared in BizTalk Hotrod Issue 3.  Wow – this issue was a long time in coming, but it looks well worth the wait.  Looks like a ton of great content once again.  If you have any comments on the article, please leave them with this post – I’d love to discuss it with you.

My article on BizTalk host throttling appeared in BizTalk Hotrod Issue 2 – Todd VanNurden and Sal Cincotta have done a great job with assembling and editing content, so be sure to take a look at the whole issue.  I’m hoping to write a follow-up piece that discusses custom throttling techniques in a future issue.

(And before you ask, I don’t own a suit nearly half as nice as the one Todd has photoshopped me into for the magazine.)