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

Have you ever created a custom monitoring or troubleshooting tool (or data store) for working with BizTalk, and wanted the ability to launch the HAT (Health and Activity Tracker) tool in a particular context?  Here are the command line parameters that will enable you to do just that…

First, though you can typically launch the HAT tool from "C:\Program Files\Microsoft BizTalk Server 2006\BTSHatApp.exe", for a production tool you probably want to read the install location of BizTalk from the registry at “SOFTWARE\Microsoft\BizTalk Server\3.0\InstallPath.”

The command line syntax looks like:

BTSHatApp.exe “btshat:“ViewName:<OrchDebugger|MessageFlow|SvcInstQuery> MgmtSvr:<your server> MgmtDb:<your mgmt db> SvcInstId:<service instance id> [MsgId:]<optional msg id>””

OrchDebugger and MessageFlow bring up the expected HAT views that you are familiar with.  SvcInstQuery will actually open the BizTalk Admin console, with a query set up so you can see a live service instance with associated messages, etc.

You can also launch with the name of a saved tracking query, as in:

BTSHatApp.exe "c:\program files\microsoft biztalk server 2006\tracking\queries\MessagesSentInPastDay.trq"

The BizTalk management pack for Microsoft Operations Manager appears to use this command line interface so that it can provide built-in tasks to launch HAT with the context present in captured event log entires.  This means that if you have the MOM operator console installed on a machine that is joined to a BizTalk group, you have a nicely integrated set of troubleshooting tools.

A flat file schema can be configured to generate empty elements for empty content – using the “Generate Empty Nodes” option.

It seems that at runtime, the flat file dissasembler can generate “<foo></foo>” for these empty nodes in cases where “Validate Instance…” in the IDE would have generated “<foo/>”.

Where this can cause pain is if you receive a message like: “<foo><bar></bar></foo>”

into your orchestration, and then do a series of assignments like:

xmlDocVariable = myMessage;
// xmlDocVariable2 initialized because xmlDocVariable is needed for other things...
xmlDocVariable2.LoadXml(xmlDocVariable.OuterXml);
myMessage2 = xmlDocVariable2;

At this point, myMessage2 is going to be the serialized representation of xmlDocVariable2.  By default, you will now get:

<foo>
..<bar>
..</bar>
</foo>

Notice you now have carriage returns, line feeds, and spaces (shown here as periods) involved.  Depending on how you now go after /foo/bar, this can be bad (i.e. you won’t get empty content when you might expect it.)  You can avoid this behavior by doing:

xmlDocVariable2.LoadXml(xmlDocVariable.OuterXml);
xmlDocVariable2.PreserveWhitespace = true;
myMessage2 = xmlDocVariable2;

Thanks to Tomas and Carlos for setting me straight on PreserveWhitespace – I was trying to set it before the call to LoadXml, and this doesn’t work.  Never a dull day in BizTalk land…

The documentation for PreserveWhitespace is a little strange.  This functionality would seem to be better represented as parameters to Load/Save, rather than as a property…

“If PreserveWhitespace is true before Load or LoadXml is called, white space nodes are preserved; otherwise, if this property is false, significant white space is preserved, white space is not.  If PreserveWhitespace is true before Save is called, white space in the document is preserved in the output; otherwise, if this property is false, XmlDocument auto-indents the output.”