Visual Studio Team System (VSTS) Blog - by Neno Loje : TFS Process Customization

How to integrate Microsoft Security Development Lifecycle (SDL) into your TFS process template

neno — Mon, 05 Oct 2009 11:13:00 GMT

Downloads:

Additional information:

Setting Remaining Work to Zero when closing a work item in TFS

neno — Thu, 30 Jul 2009 08:12:00 GMT

Question:

How can I make sure that the "Remaining Work" field is set to 0 when the work item is closed (for example when associating a work item during checking-in)?

Short Answer:

You can achieve this using the <COPY> rule on the transition to the "Closed" state.

Step-by-Step instructions:

For the desired transition (in this example from "Active" to "Closed").
Add a field reference to "Microsoft.VSTS.Scheduling.RemainingWork"
Add a new rule of type "COPY"
Choose From = "value" and enter value = "0"
The resulting XML should look something like
Verification: After transitioning a task work item from "Active" to the "Closed" state "Remaining Work" is set to zero.

What are Test Name, Test Id, and Test Path used for?

neno — Sat, 30 May 2009 20:49:05 GMT

If you create a work item out of a test result like this…

… the three test fields get populated by Visual Studio:

Read all details here: http://msdn.microsoft.com/en-us/library/ms194965.aspx

Specifying a user upfront or: How is the developer supposed to know who will be the responsible tester?

neno — Tue, 13 Jan 2009 09:00:00 GMT

In a small team this sounds like oversize, but in mid-sized large teams it's common that you do not know who is going to be the tester.

Looking at the Bug workflow from MSF Agile:

while "Active" the project lead decided if and when the bug is going to be fixed and assigns it to the responsible developer.
between "Active" and "Resolved" is where the developers implements the fix.
between "Resolved" and "Closed" is where the tester verifies the fix.

When the developer finishes coding he changes the state from "Active" to "Resolved", e.g. by checking in and associating the changeset with the work item.

But by doing so the work item is still assigned to him. In our scenario he doesn't know who will be the responsible tester to verify the fix. So who knows?

The project lead might have that information. So either we assign it back to the project lead to make him assign it to as tester or we make the project lead specify the tester upfront (with the ability to change it afterwards if necessary).

In this example we'll implement the second approach.

Objective

Ask for the Tester when creating the bug and automatically u.se it for the transition from "Active" to "Resolved"

Required Work Item Customization

Step 1: Add a new string field to hold the tester
In this example we will make it a required field (<required/>) and ensure that it contains a valid user (<validuser/>).

<FieldDefinition> type="String" name="Tester" refname="TeamSystemPro.Samples.Tester">
<REQUIRED />
<VALIDUSER />
</FieldDefinition>

Step 2: Add a rule to the transition from "Active" to "Resolved"
Automatically copy the value of the tester field to the Assigned to field.

<FieldReference refname="System.AssignedTo">
<COPY from="field" field="TeamSystemPro.Samples.Tester" />
</FieldReference>

Result

When creating a new bug it's now required to select a Tester before it can be saving.

When choosing "Resolved" for the state "Assigned to" will be automatically filled with the contents from the "Tester" field.

The history correctly shows the change in the "Assigned To" field from the developer (here: "Neno Loje" to the tester (in this case: "Administrator")

Happy Customizing!

Using TFS for non-development projects

neno — Mon, 12 Jan 2009 15:00:00 GMT

Team Foundation Server is easily customizable and equipped with a general purpose workflow or state machine. So you might ask yourself: why not put a non-development or rather related process in TFS instead of using separate software.

Showcase #1: Lead Management

Since here at AIT TeamSystemPro Team we are TFS consultants we decided to not use a commercial CRM tool for managing our leads but rather customize a team project in TFS for this matter.

Here are a few impressions of the experience:

Work Item queries:

Work Item layout:

in Outlook (via TeamCompanion)

The pretty simple workflow behind it:

Showcase #2: Customer Support

Needless to say that the TFS support that we offer is tracked using work items as well:

Showcase #3: List of managed TFS instances

Every TFS instance that we manage has a corresponding record:

Your Feedback

Do you have an interesting idea or have you used your TFS to support a non-dev related process? Feel free to leave me a comment or use the contact link – thanks!

Using rich HTML descriptions instead of plain text

neno — Sun, 11 Jan 2009 11:34:00 GMT

Objective

Allow rich HTML formatting in description fields of the MSF Agile process template.

Note: The MSF CMMI process does support HTML formatting by default. In order to use it you have to enable the formatting toolbar (see Step 6 below).

Work Item Customization

Step 1: Add a new HTML description field

Since the System.Description field is defined of type string as opposed to type HTML we need to create a new field:

Step 2: Change the work item layout

Use your own HTML field instead of System.Description

Step 3: Refresh Work Item cache

Right-click "Work Items" in Team Explorer and select "Refresh".

Step 4: Enable the formatting toolbar

Right-click on the Visual Studio toolbar, find and click "Formatting":

A new toolbar will appear:

Result

Click into the description field and use the toolbar to format your input:

Optional Step 5: Copying the old descriptions to the new HTML field

It would be a pity to loose the existing descriptions so let's write a small utility using the Team Foundation Object model to copy the "old" descriptions to the new HTML field:

static void CopyOldDescriptions()
{
    // TODO: Change these values:
    string tfsName = "servertogo";
    string tfsProjectName = "WorkItemCustomization";
    string tfsHtmlDescriptionFieldName = "DescriptionHtml";
    string tfsWorkItemType = "Task";

    using (TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(tfsName))
    {
        WorkItemStore wit = (WorkItemStore)tfs.GetService(typeof(WorkItemStore));
        WorkItemCollection result = wit.Query(String.Format("SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = '{0}' AND [System.WorkItemType] = '{1}'", tfsProjectName, tfsWorkItemType));
        List<WorkItem> affectedWorkItems = new List<WorkItem>();
        foreach (WorkItem wi in result)
        {
            if (wi.Description.Length > 0)
            {
                // Set new description
                string value = (string)wi[tfsHtmlDescriptionFieldName];
                if (String.IsNullOrEmpty(value))
                {
                    wi[tfsHtmlDescriptionFieldName] = wi.Description.Replace("\n", "<br>");
                }
                else
                {
                    wi[tfsHtmlDescriptionFieldName] += "<br><p>Old description:</p><p>" + wi.Description.Replace("\n", "<br>") + "</p>";
                }

                // Delete old description
                wi.Description = String.Empty;

                affectedWorkItems.Add(wi);
            }
        }

        if (affectedWorkItems.Count > 0)
        {
            wit.BatchSave(affectedWorkItems.ToArray());
            MessageBox.Show("Items updated: " + affectedWorkItems.Count);
        }
        else
        {
            MessageBox.Show("Nothing to do.");
        }
    }
}

Happy formatting. :-)

Specified cast not valid when trying to create a new work item

neno — Sat, 10 Jan 2009 18:27:19 GMT

Problem description

When trying to create a new work item you receive the following error?

Cause

Thanks to this thread we now know that this message is caused by a DateTime Control in a WIT definition when its associated with a String field.

Fix

Only assign DateTime fields to DateTime controls.

Workflows of MSF Agile and CMMI Process Templates for TFS

neno — Fri, 09 Jan 2009 00:24:36 GMT

When trying to decide which of the two MSF Process Templates - Agile vs. CMMI Process Improvement - for TFS is the right starting point for your company, it helps to compare the work item types and its workflows.

You can download the full guidance from:

MSF for Agile Software Development Process Guidance
MSF for CMMI Process Improvement Guidance
Also a good source: Microsoft's Process Templates and Tools website

MSF for Agile Software Development

featuring 5 work item types: Bug, Requirement, Quality of Service Requirement (QoS), Risk and Task.

Work Item Type: Bug

Work Item Type: Scenario

Work Item Type: Quality of Service Requirement (also known as "technical requirement")

Work Item Type: Risk

Work Item Type: Task

MSF for CMMI Process Improvement

featuring 7 work item types: Bug, Requirement, Change Request, Issue, Review, Risk, Task

Work Item Type: Bug

Work Item Type: Requirement

Work Item Type: Change Request

Work Item Type: Issue

Work Item Type: Review

Work Item Type: Risk

Work Item Type: Task

As a personal note:

Both templates are a great starting point. The agile template might be a bit more lightweight whereas the CMMI template might fit more the vocabulary and processes that you are used to.

However, both are really just a starting point. In customizing the process you get way more out of TFS than with just using the built-in process templates.

Specifying a minimum size for controls on the work item form

neno — Wed, 01 Oct 2008 20:21:25 GMT

If you try to set the minimum size for a control you now need to specify a SizeType like "(50,100)" instead of "50,100".

Error message (from witimport.exe):

The 'MinimumSize' attribute is invalid - The value '50,100' is invalid according to its datatype 'SizeType' - The Pattern constraint failed.

Using a minimum size you can create multiple large text boxes on the work item form layout:

Documentation: Team Foundation Server SDK (online version)

neno — Sat, 23 Feb 2008 13:55:34 GMT

From the contents:

Team Foundation Server Extensibility

Team Foundation Server SDK Architecture

How to: Run Team Foundation Server SDK Samples

Team Foundation Core Services

Work Item Tracking Extensibility

Source Control Extensibility

Data Warehouse Extensibility

Reference for Team Foundation Server SDK

Link: http://msdn2.microsoft.com/en-us/library/bb130146(VS.80).aspx

V-Modell XT Generator creates TFS Process Templates

neno — Wed, 21 Nov 2007 21:07:00 GMT

Microsoft Germany [1], The Center of Software Concepts at the Technical University of Munich [2] and Zühlke [3] released the V-Modell XT Generator [4] that creates process templates for working with the V-Modell, which is a process modell widely asked for by German customers working for the public sector. It is available via Codeplex.

Congratulations to Marcus Alt [5] from Microsoft and the whole team for realising this project which was quite a bit of work as I experienced first hand!

[1] http://www.microsoft.de/

[2] http://zfs.in.tum.de/

[3] http://www.zuehlke.com/index.php?id=2&L=2

[4] http://www.codeplex.com/VModellXTTFS

[5]http://blogs.msdn.com/marcalt/

Some impressions:

CollabXT V-Modell® XT Generator

Instantiated V-Modell® XT in TFS

V-Modell® XT Work Items in in TFS

V-Modell® XT Work Items in WebAccess

Changing TFS email notifications to link to Team System Web Access

neno — Fri, 31 Aug 2007 14:44:37 GMT

Thanks to this MSDN Forums post I was able to change the link included in every TFS notification e-mail to point to TSWA instead of the project portal.

Here’s the full story:

When using project alerts to get notified about work item changes you get an email containing a link to the project portal:

If you follow the link you might get a bit dissapointed when looking at this very basic work item details page:

Since Team System Web Access is now avaible from Microsoft free of charge we can change the link in the template for all notification messages to point to the new TSWA.

Changing the e-mail template

On the TFS app tier open the folder:
%ProgramFiles%\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\v1.0\Transforms
Create a backup of the file WorkItemChangedEvent.xsl, which we will be editing in the next step.
Replace the text:

<xsl:value-of select="DisplayUrl" />

with:

<xsl:value-of select="concat(substring-before(DisplayUrl,':8080/WorkItemTracking/WorkItem.aspx?artifactMoniker='),':8090/wi.aspx?id=',substring-after(DisplayUrl,'artifactMoniker='))" />

The bold printed 8090 is the port where you installed TSWA at.
Save the file and you are done.

If you now get a new notification e-mail and click on the link you’ll see the following much nicer work item details form provided by TSWA:

Note: Be aware that you either need to use Windows authentication with TSWA to make this work or you need to be already logged in and the session must be still alive.

I published a 2nd part: Changing TFS emails to link to Team System Web Access – Part 2

Tool for creating links to pages on Team System Web Access

neno — Fri, 31 Aug 2007 14:34:20 GMT

Would you like to send links to work items, team projects or source files on Team System Web Access?

For work items
… you can find the answer in the offical TSWA FAQ:

Q: What’s the URL to use if I want to send the link of a specific work item?

A: Work item links use the follwing format:

http://[TSWA:port]/wi.aspx?id=[WorkItemID]

For Team Projects
… it also pretty simple:

http://[TSWA:port]/index.aspx?pname=[ProjectName]

For Source Files
… it’s a little bit more “interesting” (thanks to Hakan from Microsoft for reveiling the details behind this secret).

It’s a bit tricky but here it goes:

http://[TSWA:port]/UI/Pages/Scc/ViewSource.aspx?scc-item=[ItemData]

ItemData is the HtmlEncoded output of the query string something like “id=10&cs=-1”

id: the ID of the item in source control (you need to know this instead of the file path)

cs: changeset number (-1: latest)

In your example, the file id is 151611. So,

HtmlEncode(“id=151611&cs=-1”) -> “id%3D151611%26cs%3D-1”

https://[TSWA:port]/UI/Pages/Scc/ViewSource.aspx?scc-item=id%3D151611%26cs%3D-1

[We’re planning to provide more friendly URLs in a future version, similar to wi.aspx approach]

To make it fast and more convenient to create links to TSWA I created a small tool to help you with it:

It should be mentioned that this tool has a lot of room for improvement. :-)

You can download the source from an updated version here.

Creating a separate work item form layout for Web Access

neno — Wed, 29 Aug 2007 16:32:00 GMT

Right now custom work item controls [1] are not supported by Team System Web Access [2]. Instead your custom control you will see this unpleasant message: “Unable to create workitem control ‘ControlName’”.

While this is a sad thing for us users does that mean that we shouldn’t use Web Access? No, of course not…

One solution is to create a separate work item form layout for Web Access and remove all custom controls from it. (thanks to Serkan and Marcus for pointing me in that direction.)

All you need to do is duplicate the <layout> information in your work item xml file.

Let’s do it

The first section gets a target-attribute with the value “WinForms” like this:

<Layout Target=“WinForms”>

The second targets the “Web”:

<Layout Target=”Web”>

Last thing you need to do is change the “Type” attributes of all controls in the web layout to use “FieldControl” instead of your custom control.

Review the results

If you take my Priority Control example from [1] it would look like this:

Windows layout (in Team Explorer) will show the friendly priority list (= the custom control):

Web layout in Team System Web Access doesn’t show the control, but instead it displays the regular field control. Not nice, but usable – and much better than the initial error message we had.

[1] http://msmvps.com/blogs/vstsblog/archive/2007/07/07/starting-using-custom-work-item-controls.aspx

[2] http://msmvps.com/blogs/vstsblog/archive/2007/08/27/free-add-on-team-system-web-access-tswa-power-tool-by-microsoft.aspx

Getting started using Custom Work Item Controls

neno — Sat, 07 Jul 2007 15:26:44 GMT

Since Service Pack 1 [1] we have the ability to create our own controls to display field value within a work item form which gives us great flexibility.

However there are two caveats with custom work item controls right now that aren’t solved:

They do not work with Web Access [2] so it’s not a choice for people that heavily rely on the web client.
They need to be deployed to the machine of every user accessing TFS.

Setting the stage

As an first realistic example we could make the priority field a little prettier. I mean the allowed values “1”, “2”, and “3” are not very descriptive. We don’t want to create a new field or change the values since we used this field already. So the solution would be to create a custom work item control on top of the existing values that displays something else.

I plan to create a new control that has a combobox on it and will display something nicer than the real values that are stored in the database. The complete source code is attached for reference.

1. Create the Work Item Control

A custom work item control is essentially a regular Windows Forms control. It has to derive from Control and implement IWorkItemControl.

The loading takes place in IWorkItemControl.InvalidateDatasource, the saving in IWorkItemControl.FlushToDatasource. The bold code indicates peaces that were necessary to implement my wishes. The rest is infrastructure and is repeated for every control you’ll write.

Here’s the code:

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Drawing;
using System.Data;
using System.Text;
using System.Windows.Forms;
using Microsoft.TeamFoundation.WorkItemTracking.Controls;
using Microsoft.TeamFoundation.WorkItemTracking.Client;

namespace TeamSystemPro.Samples.WorkItemControls
{
    /// 
    /// Work Item Control for displaying the priority (can be 1,2, or 3 in MSF) in a more descriptive way then just showing the numbers.
    /// 
    /// 
    /// Custom controls need to derive from Control.
    /// Typically custom controls are built from UserControl.
    /// The control needs to implement IWorkItemControl.
    /// This is defined in Microsoft.TeamFoundation.WorkItemTracking.Controls.dll assembly that can be found from VS installation folder, typically ":\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies".
    /// Add reference to that assembly and line "using Microsoft.TeamFoundation.WorkItemTracking.Controls;" in code.  
    /// How it works:
    ///   After the control is loaded, a reference to work item is passed to the control using IWorkItemControl.WorkItemDatasource property.
    ///   The control is asked to display its data using IWorkItemControl.InvalidateDatasource method.
    ///   The control is required to update any values directly in WorkItem object itself when user changes data. 
    /// 
    public partial class PriorityControl : UserControl, IWorkItemControl
    {
        private WorkItem workItem;
        private string workItemFieldName;
        private IServiceProvider serviceProvider;
        private System.Collections.Specialized.StringDictionary properties;
        private bool readOnly = false;

        public PriorityControl()
        {
            InitializeComponent();
        }

        #region IWorkItemControl Members

        /// 
        /// Raise this events before updating WorkItem object with values. When value is changed by a control, work item form asks all controls (except current control) to refresh their display values (by calling InvalidateDatasource) in case if affects other controls 
        /// 
        public event EventHandler BeforeUpdateDatasource;

        /// 
        /// Raise this event after updating WorkItem object with values. When value is changed by a control, work item form asks all controls (except current control) to refresh their display values (by calling InvalidateDatasource) in case if affects other controls 
        /// 
        public event EventHandler AfterUpdateDatasource;

        /// 
        /// Control is asked to clear its contents
        /// 
        void IWorkItemControl.Clear()
        {
            cboPriorities.SelectedIndex = -1;
        }

        /// 
        /// Control is requested to flush any data to workitem object. This usually happens during save operation or when the form is left. In most cases data will be written to workitem immediately on change and hence this will not need implementation. Some customers want a way to do operations during save, and this is the closest thing we got. If you do need a way to react to before-save & after-save events, pls let us know in forums given below and we'll consider for future revision.
        /// 
        void IWorkItemControl.FlushToDatasource()
        {
            this.BeforeUpdateDatasource(this, EventArgs.Empty);
            workItem.Fields[workItemFieldName].Value = Convert.ToString(cboPriorities.SelectedIndex + 1);
            this.AfterUpdateDatasource(this, EventArgs.Empty);
        }

        /// 
        /// Asks control to invalidate the contents and redraw. At this point, control can read from work item object and display/refresh data.
        /// 
        void IWorkItemControl.InvalidateDatasource()
        {
            if (IsInitialized())
            {
                int currentValue = (int)workItem.Fields[workItemFieldName].Value;
                cboPriorities.SelectedIndex = currentValue - 1;
            }
        }

        /// 
        /// A property bag of all attributes specified in work item form xml for this control. Custom attributes are allowed and can be used to pass parameters specific for this control from work item type xml.
        /// 
        System.Collections.Specialized.StringDictionary IWorkItemControl.Properties
        {
            get { return properties; }
            set { properties = value; }
        }

        /// 
        /// Tells the control to display in readonly mode.
        /// 
        bool IWorkItemControl.ReadOnly
        {
            get { return readOnly; }
            set { readOnly = value; OnReadOnlyChanged(); }
        }

        /// 
        /// Gives pointer to IServiceProvider if you intended to access Document service or VS Services. If services are not needed, do nothing in this method.
        /// 
        /// 
        void IWorkItemControl.SetSite(IServiceProvider serviceProvider)
        {
            this.serviceProvider = serviceProvider; 
        }

        /// 
        /// This passes reference to source work item object. Cast this object to WorkItem type.
        /// 
        object IWorkItemControl.WorkItemDatasource
        {
            get { return workItem; }
            set { workItem = value as WorkItem;  }
        }

        /// 
        /// The field name if the control is associated with a field name in work item form xml. A custom control can be associated with 0 or 1 work item field.
        /// 
        string IWorkItemControl.WorkItemFieldName
        {
            get { return workItemFieldName; }
            set { workItemFieldName = value; }
        }

        #endregion

        private bool IsInitialized()
        {
             return (!this.IsDisposed &&
                 workItem != null &&
                 !string.IsNullOrEmpty(workItemFieldName) &&
                 workItem.Fields.Contains(workItemFieldName));
        }

        private void OnReadOnlyChanged()
        {
            cboPriorities.Enabled = !readOnly;
        }
    }
}

Additionally you need to create an XML file with the .wicc extensions which contains the name of your assembly file as well as the full-qualified name (i.e. namespace and classname) of your control class:

So you have your control as well as the .wicc-file (which is necessary for registration):

2. Deploy the Work Item Control

Although you could simply copy the two files (.dll and .wicc) to the “Microsoft\Team Foundation\Work Item Tracking\Custom Controls” under Environment.SpecialFolder.CommonApplicationData (we could also use the folder unter then under Environment.SpecialFolder.LocalApplicationData), but I decided to create a new MSI setup with Visual Studio which might look like this:

3. Reference the new control in a Work Item Type

After the control is deployed just change the type attribute for the control in the work item type XML. The Type should reference the name of the .wicc-file.

Now you can import your modified work item type XML (you need to use witimport as the Process Template Editor does not support custom controls right now), refresh the cache by right-clicking the Work Items node in Team Explorer and press “Refresh”.

Further recommended reading:

How to use Custom Controls in Work Item Form [3]
Communicating between custom controls: Building parent/child controls [4]

Enjoy increasing your Work Item UI experience through custom controls!

-Neno

[1] http://msmvps.com/blogs/vstsblog/archive/2006/12/15/download-visual-studio-2005-team-suite-team-foundation-server-service-pack-1-sp1.aspx

[2] http://www.devbiz.com

[3] http://blogs.msdn.com/narend/archive/2006/10/02/How-to-use-Custom-Controls-in-Work-Item-Form.aspx

[4] http://blogs.msdn.com/narend/archive/2006/10/19/communicating-between-custom-controls-building-parent-child-controls.aspx

File Attachment: WorkItemCustomControlDemo.zip (25 KB)

Undocumented attributes for controlling the Work Item form layout

neno — Sat, 07 Jul 2007 14:42:40 GMT

Naren [1] revealed a few very interesting on hidden attributes his blog [2] which you definitely should take a look at since they let you solve some problems as the following ones:

Control the height of two text boxes that were placed vertically on one tab

When placing more than one text box on a tab page you will notice that all text boxes have the same height except the last one which can be annoying if you use HTML and expect the writer to write a lot.

Using the “MinimumSize” attribute in the Work Item Type XML you can specify the minimum width and height that the control has to have.

Resulting in a much more nice looking writing experience:

Show the same field twice in different places

Sometimes it makes sense to place the same field on two places for example in the general area as well as on a tab. If you do so you would get an error.

You can use “Name” attributes with different values to allow the field to be displayed multiple times.

This leads to the desired effect. Note that if you enter something in the one field it will automatically appear in the other text field after leaving the control.

So here’s the background by Naren. A must read for people customizing Work Item types:

<Control FieldName="control name" Type="FieldControl | DateTimeControl | HtmlFieldControl | LinksControl | AttachmentsControl | WorkItemClassificationControl | WorkItemLogControl" Label="label text" LabelPosition="Top | Bottom | Left | Right" Dock="Fill | Top | Bottom | Left | Right" Padding="(left, top, right, bottom)" Margin="(left, top, right, bottom)" ReadOnly="True | False" />

Attributes that weren’t documented:

MinimumSize: The minimum size the control should occupy in the form. If vertical space is not enough, then a scrollbar is shown to keep its minimum size. Without this attribute, the controls are drawn with their default sizes (unless controls in other tabs take larger space that incrasing whole tab’s size). The syntax for it's value is "(width,height)" (In regex format it is "^$\d+\,\d+$$").

Name: If you want to add same field to be displayed in more than one place, it is possible but the Name attribute should be set to unique values for both – so that the system identifies each control uniquely. It is useful to show same control in various places based on context of tabs.

[Update: 3/12/07]

Below are special attributes available for specific controls:

NumberFormat (for FieldControl only): Useful if a number value is displayed in the field. Possible values: WholeNumbers, SignedWholeNumbers, DecimalNumbers, SignedDecimalNumbers. Setting this attribute determines what characters are allowed to be entered in this control.

MaxLength (for FieldControl only): Maximum length of allowed characters for field control in form UI.

Format (for DateTimeControl only): One of values of DateTimePickerFormat enum. Possible values as given in help are: Long, Short, Time and Custom. Custom format can be set by having 'Custom' as value for this attribute, and setting another attribute named CustomFormat with actual custom format string.

[1] http://blogs.msdn.com/narend/

[2] http://blogs.msdn.com/narend/archive/2007/02/09/hidden-attributes-to-control-your-work-item-form-layout.aspx