TFS is a great tool – don’t get me wrong – but there are some things conspicuously missing from TFS out-of-the-box and the TFS Power Tools. One of these is a way to update work items published to a large number of projects. Certainly, you can use the witadmin command-line tool to import work items or, if the command-line frightens you, you can use the Work Item Import tool in the TFS Power Tools. While both of these work fine, they only import a single work item into a single project. And here’s where TFS fails the TFS administrator that is responsible for an implementation with many projects – you could spend all day importing a single work item across 100 projects. And if you have to import multiple work items? Well, there goes your vacation.

So … let’s break this down. You have a highly repetitive task and differs by only a couple of variables that you want to do over and over and over again. Sounds like a good application of our old friend, the looping construct, right? In fact, it certainly is. Let’s start with what we need to do to import a single work item into a single project:

private void ImportWorkItem(string workItemFilePath, Microsoft.TeamFoundation.WorkItemTracking.Client.Project project)
{
    //Need to get the raw XML for the work item.
    var fileInfo = new System.IO.FileInfo(workItemFilePath);
    string workItemXml = String.Empty; 
    using (var reader = fileInfo.OpenText())
    {
        workItemXml = reader.ReadToEnd();
        reader.Close();
    }
    //Import ... 
    project.WorkItemTypes.Import(workItemXml);
}

Really … it is that simple.

The fun part comes when you want to take this simple concept and wrap it up in a nice pretty bow that allows a TFS Admin to update multiple work items across multiple projects. It’s not hard … except for the fact that I am UI-challenged and anything that is functional and looks somewhat usable is not my strong suit. But … I did manage to get it done. Here it is:

Running the tool is pretty straightforward. Start the EXE. It will then prompt you to select a Team Project Collection, which gets you to this screen. Use “Browse…” to select the work item files that you want to import. These should be in the same format as you would use in the project template. Then you select the projects that you want them imported into. Hit OK and away it goes. It will take a few minutes, so go get yourself some coffee. Or Mountain Dew. Then relax and surf the web a bit … after all, you did tell the boss that this was a tedious, time-consuming process right?

You can download this tool on MSDN Code Samples.

It is essential that you mark your StreamInsight adapter configuration classes with either the [Serializable()] or [DataContract()] attributes. Keep in mind that the StreamInsight engine can be run either in process or remotely … and, if remote, these classes will have to be serialized on the wire. The serializable attribute is easier, but the DataContract attribute - through the [DataMember()] and the [IgnoreDataMember()] attributes - allows you to be more explicit in specifying which members actually go on the wire. I looked (quickly) and didn’t see this document but that doesn’t mean that it isn’t.

Now … what can happen if you don’t do this? Bad things. This happened to me yesterday and simply reinforced why I shave my head (so I can’t rip my hair out). So … everything had been working fine. I was making some changes to an adapter to try to resolve a Heisenbug caused by a race condition during the adapter tear down (I’ll discuss some of these challenges later, I think). When I went to run to test, I started running into exceptions when starting the query. It was an XmlException with the message:

Name cannot begin with the '<' character, hexadecimal value 0x3C.

Huh? I checked through everything and there were no members that began with a “<”. In fact, the C# compiler won’t let you do this, even if you use the “@” character (rightfully so … I mean, why on earth would you do that??). Examining the full stack trace, I could see that it was happening during the stream creation while serializing something. Once I loaded the debug symbols, I found that the offending member name was “<LogName>k__BackingField”, which certainly does begin with a “<”. Of course, there was no member that I declared in the code … there’s no way that I would even try to declare such a thing. It turns out, however, that the C# compiler will declare the backing fields for automatic properties like this and, for some reason, it chose yesterday to start blowing up on me. I finally found that the configuration class for a specific adapter was not marked as serializable (and I know better than this) and, once I changed it, all worked just fine.

I gotta tell you, I do so hate these mysterious errors.