TFS WorkItem lazy loading

This is going to be a short post.

For performance improvement, TFS enables caching (as mentioned in previous post) and lazy loading in many places. These means reduce the amount of server calls as well as improves client-side UI rendering.

Here is a note to those who are coding against TFS WIT OM. Assuming we try the following code to get a Work Item:
    WorkItem wi = workItemStore.GetWorkItem(itemId).
This is one server call. But keep in mind that the instance ‘wi’ doesn’t contain all the information of the item on the server. Say, if now you want to know the revision details of the item with the following code:
    foreach (Revision rev in wi.Revisions) { … }
This results in another server call of GetRevisions() on the work item – yes, the lazy loading.

WorkItemStore cache synchronization

Eyes open – if you notice inconsistent data between various TFS (Team Foundation Server) Work Item Tracking utilities, first check if Work Item Store cache is sync-ed properly.

Here is an example. Someone writes a small utility to export, edit, and import GL (Global List) with TFS WIT OM. To the simpliest, s/he may need to call WorkItemStore.ExportGlobalList() and WorkItemStore.ImportGlobalList(). So, s/he uses the tool to author a modified GL and imports it to the target TFS server. AND, s/he expects everyone can see his changes now.

Well, in reality, things are not so simple. The tricky part is that TFS WIT client is optimized with a local cache of the Work Item Store information, among which is GL. There are only few operations that forces the WIT client to sync the local cache to the server, e.g. loading Team Explorer package, etc. To continue on with the example, if I was having a VS Shell opened while I used my toy application to import the new GL to the server, I can now observe the following weird behavior:

1. in this shell, if I try “Open Global List from Server” using the PTE (Process Template Editor), my latest changes wouldn’t show up.
2. weirdly, if I use my toy application (imaging it is a service that has a life WorkItemStore instance), the changes would show up.

So, how to resolve the problem? The answer is quite simple, call WorkItemStore.SyncToCache() to programmatically sync the WIT cache.

From XSD to Object Model (OM)

From time to time, I have to design xml schema (.xsd files) for specifying the syntax of the data transferred between my application components. Having some tools to visually create the schema and automatically generate code for the object model is probably preferred by every developer(?). Well, at least for someone like me who is “lazy” and found of generated code :-). 

The following information should be nice to those who are trying to find such a solution.

1. Xml schema authorization.
   One can certainly hand-craft it in notepad. But, that’s definitely what I am looking after. On my office dev box, I have Visual Studio 2008 SP1 installed. Nicely, Orcas SP1 re-includes the Xml Schema viewer, which renders a nice hierarchical view of the schema. Unfortunately, it is not much helpful to the editing job.
   If you are looking for a really power tool, take a look of Liquid Xml Studio. The “free” Community Version is good enough for “visually” creating a schema. The licensed version is documented to be able to generate databinding code. Well, I am not so rich to have the money for that, particularly when there is free tool around the corner.
2. Databinding class generation.
   I am using XSD.exe that comes with .Net SDK to generate object models for my C# projects. The SDK is a free download from Microsoft Download. After installation, the tool can be found at %ProgramFiles%\Microsoft Visual Studio 8\SDK\v2.0\Bin, assuming this is on a 32-bit Windows.
   Since I need to generate OM classes from the schema, I can use the following command
           xsd.exe my_schema.xsd /c /edb /namespace:yangzhenrong.com /o:\tmp
   to generate databinding-enabled C# classes with the namespace “yangzhenrong.com” in the \tmp folder.
3. Object instantiation (serialization and deserialization).
   XSD.exe generated OM classes are all serializable. Hence, it is quite easy to use an System.Xml.Serialization.XmlSerializer to load data into OM by deserializing the XML data conforming to our source schema. I am tired repeating typing the serialization and deserialization code again and again, though. So, I have the following generic serializer implementation to allow me quickly construct a serializer to load data to/from the XML data (in my use cases, the XML data is always stored in a string blob).

============ code sample starts ============

public class GenericSerializer<T>
{
  public T Deserialize(string ruleBlob)
  {
    if (string.IsNullOrEmpty(ruleBlob))
    {
      throw new ArgumentNullException(“ruleBlob”);
    }

    XmlSerializer serializer = new XmlSerializer(typeof(T));

    using (StringReader strReader = new StringReader(ruleBlob))
    using (XmlReader xmlReader = XmlReader.Create(strReader))
    {
      return (T)serializer.Deserialize(xmlReader);
    }
  }

  public string Serialize(T rule)
  {
    XmlSerializer serializer = new XmlSerializer(typeof(T));

    using (MemoryStream memStrm = new MemoryStream())
    {
      serializer.Serialize(memStrm, rule);
      memStrm.Seek(0, SeekOrigin.Begin);
      using (StreamReader sw = new StreamReader(memStrm))
      {
        return sw.ReadToEnd();
      }
    }
  }
}

 ============ code sample ends =============

Well, that’s it. I hope this small tip can save some time for someone out there :-)

Hello World!

Here I am … greeting all my blog readers from the front of my office PC…