Loïc Baumann's Blog

Team System and .Net stuffs

February 2008 - Posts

Modifying Work Item Type definition using the Object Model

I'm in the process of easing the installation of the Work Item Creator.
To do that, I wanted to detect in runtime if a given Team Project doesn’t have its Work Item Types (WITs) supporting hierarchy and then asking the user to add them.
It’s not very complicated to do, once you know how to do it (as always you might say).

To get the definition of a given Work Item Type and add a field, it’s not complicated:

 2412 // Get the Xml Document for the given WIT

 2413 XmlDocument doc = wit.Export(false);

 2414 XmlElement fields = doc.SelectSingleNode("*/WORKITEMTYPE/FIELDS") as XmlElement;

 2415 

 2416 // Look for each field, and add the ones that are not present

 2417 XmlElement field = fields.SelectSingleNode("FIELD[@refname="Cegedim.ParentWI"]") as XmlElement;

 2418 if (field == null)

 2419 {

 2420     field = doc.CreateElement("FIELD");

 2421     field.SetAttribute("name", "ParentWI");

 2422     field.SetAttribute("refname", "Cegedim.ParentWI");

 2423     field.SetAttribute("type", "Integer");

 2424     field.InnerXml = "The ID of the Parent Work Item";

 2425     fields.AppendChild(field);

 2426 }

To validate the type before importing it:

 2453 WITValidateSucceed = true;

 2454 prj.WorkItemTypes.ImportEventHandler += new ImportEventHandler(WorkItemType_ValidationEventHandler);

 2455 WorkItemType.Validate(prj, doc.OuterXml);

 2456 if (WITValidateSucceed == false)

 2457 {

 2458     MessageBox.Show("Work Item Type couldn't pass validation, something went wrong", "Work Item Creator", MessageBoxButtons.OK, MessageBoxIcon.Error);

 2459     return false;

 2460 }

The registered event will be fired if the validation failed. Why the Validate method doesn’t return a bool, I don’t know…

 2473 void WorkItemType_ValidationEventHandler(object sender, ImportEventArgs e)

 2474 {

 2475     WITValidateSucceed = e.Severity == ImportSeverity.Error;

 2476 }

Then, you’ll have to call Import from the WorkItemTypes collection to update your type:

 2461 prj.WorkItemTypes.Import(doc.OuterXml);

prj being your Work Item “Project” instance.

Now there’s a small trick and if you don’t know it, you’ll be like me, wasting 2 hours trying to figuring out why your application is totally crashing when you try to modify two WITs in a row.

Importing an existing WIT will update the server side, but apparently the definition of your WITs are cached in local, and this cache is not updated by the Import method (it could have been…), so if you try to modify a second WIT, somehow the Team System Object Mode doesn’t like it!
The solution is not that hard though, after your import, you only have to call these two methods:

 2401 m_WIS.RefreshCache();

 2402 m_WIS.SyncToCache();

m_WIS being your instance of the Work Item Store. This way you local version is updated, and you can keep working on WIT modification!

TFS 2008's GetMergeCandidates improvements and WICreator updates

Hi all, still alive! :)
It's been a long time I didn't blog, too many things going on in life.

This is will be short. I wanted to say few things:

  1. Good job the TFS Team for the TFS 2008 Release! Especially for the GetMergeCandidates API improvement! I blogged about that in the past: in TFS 2005 it was bugged, and slow. And now I can say: "yey, it's fast and it's working!"
    Now it's bug free: I could remove the code I've made in WICreator for the "Merge by Work Items" feature.
    Before it took around 10 minutes for one API call for two branches with lots of changesets, now it's taking only 20 seconds! The integration people loved the TFS 2008 upgrade, I can tell you!
  2. As I said in a recent post on the WICreator Codeplex's project, I'm starting again working on WICreator, the "Merge by Work Items" feature is pretty stable and usable now (we use it in production for at least 4 months; we did around 30 releases with it). So I'm going to make a new Codeplex release, containing this major feature, and small other ones.
  3. I'm thinking about an "administration" part for WICreator that will do for you most of the boring tasks post setup: WITs' fields creation for hierarchy, alert registration, few configuration of the NetworkModels.xml file. I think this feature would enhance the adoption of WICreator and WINetwork.
  4. I'm going to work on a "killer feature", well, more a "flashy feature", I hope it won't take too much time or I won't be able to release it. I really hope I will find time to do it, because it's going to be great!
    One hint: WICreator is going to be .Net 3.0!

That's it people, keep in touch for coming events.

Thanks to all the people who use WICreator, drop me a comment if you use it, I'm always curious! :)