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

I’ll be doing two talks on Team Foundation Server at the upcoming Minnesota Developers Conference (MDC 2007) on August 22nd, 2007.  One talk will be on release management (branching strategies, deployment, etc.) and another on options for using Scrum with TFS.  Should be a great conference all around – four great tracks and what looks to be a great keynote on BizTalk RFID solutions.

There is a new release of QuickCounters up at http://codeplex.com/quickcounters.  Great new useability additions to the viewer application by Dave Comfort, as well as fewer priviliges required against remote servers.  See here for the quick tour…

I’ll be talking about using QuickCounters with BizTalk at tonight’s Minnesota BizTalk User Group meeting.  (Last night, I was presenting on using Scrum with Team Foundation Server at the Minnesota VSTS User Group – it’s been a busy week!)

We were having a problem with a BizTalk assembly (containing only maps) having a “project” reference to a standard C# library.  As soon as the project reference was added, we were unable to open the maps – errors along the lines of “unable to open source schema” and “unexpected error encountered…vsee\internal\inc\vscomptr.inl”.  See here for a good forum discussion on the issue that we came across.

It turns out this issue crops up if you have a VSTS unit testing project in the same solution…How is that for a strange product interaction?  Possible workarounds include removing the unit testing project (and putting it in a separate solution) or using a file reference instead of a project reference.  (If you go the latter route, go to the properties of your solution and set up the project build dependencies manually to account for this!)

We opted for file references rather than removing our unit test assembly, at least for the time being.  Hopefully this will be addressed soon…

So...almost three years ago (gulp) I wrote this article on the use of orchestration naming conventions.  In the post, I described the value of orchestration diagrams and their use throughout the development cycle.  In my current engagement, we are doing analysis on the integrations between ERP, warehousing, front-end commerce systems in multiple channels, and a PIM (Product Information Management) solution.  I'm finding that the BizTalk designer - used just as a modeling tool with the constructs that it provides but not filling in deep detail - eliminates so much of the ambiguity that a simple Visio can leave on the table.  So I thought I'd repeat my (now old) thoughts on this topic:

The opportunity exists to use an orchestration diagram in several interesting ways within a project lifecycle:

1. As a way to capture an initial high-level design, using all the orchestration shapes as intended but not yet bothering with real maps and schemas.  Stubbing out schemas (so you can declare messages and variables to be of proper types) and maps will allow you to flesh out the orchestration diagram(s) quite a bit, using the compiler as just a way to check for consistency.  All of the external system interactions, communication patterns, decision points, parallel vs. joined flows, etc. can be represented at this point in a shell orchestration.
2. As a way to gain consensus with the development team & business sponsor about whether the right functionality is indeed going to be built.  The high level design just described is a great tool for this discussion.  Put your orchestration(s) up on a wall with a projector and do a walk-through with as many of the project stakeholders as makes sense.  Or use a tool like CutePDF to print the orchestration as a PDF to send around via email.
3. As a way to estimate work.  The various shapes in your initial orchestration can often represent reasonable granularity for time estimates.
4. And finally, as a way to guide project work...Rather than starting with the entire orchestration that you created to support steps 1-3, you might find it easier to create a new orchestration that represents the path(s) you are tackling at a particular point.  You can cut/paste portions of that original orchestration or simply use it as a reference for what comes next it serves as your outline.

To help realize some of these benefits, naming conventions within an orchestration are quite important

While the naming conventions are good practice for variables, Messages, Multi-Part types, etc. they are even more import for the workflow shapes.  The goal is to ensure that the intent of each shape is clear, and that the text associated with the shape conveys as much as possible given the space constraints.  Make liberal use of group shapes where needed.  In this way, a non-technical audience will be able to use the orchestration as documentation.