Defining TFS Events

An XML Schema Definition (XSD) file defines TFS events. Fields in the event can be of any type, including lists, as long as the .NET XMLSerializer can serialize the type. You can do define an event by making the fields public, by providing a no-argument constructor, or by excluding cycles in the object graph.

Event Schemas

The following field types are supported by the filtering language. See the Subscriptions section for details.

Field Type

Example field


Priority field on a defect.


Description or Files field on a check-in notice.


CreateDate field on a defect.

Generally, every event schema must contain the following basic information.

  • Artifact URI or Server URI—A string or list of URIs to the artifacts that are relevant for this event or the Server URI if the event is not associated with an artifact. This information allows event recipients to uniquely identify the source server and artifacts.

  • Team Project URI—A string or list of URIs to which relate to the team projects event or its relevant artifacts. This allows event recipients to uniquely identify the target team projects. The Team Project URI can be omitted if the event pertains to the whole Team Foundation Server or if it does not pertain to any artifacts.

The following is an example XSD file that shows part of the definition of a "defect changed" event. Visual Studio Team System tool vendors can add an XSD file for each event type they publish to a folder for Team Foundation Server, or register with the Team Foundation Registration Service.

<xsd:schema xmlns:xsd=""
  <xsd:complexType name="DefectChangedEventType">
       <xsd:element name="title" type="xsd:string"/>
       <xsd:element name="status" type="tns:StatusType"
       <xsd:element name="changeTime" type="xsd:dateTime"/>
<xsd:element name="artifactUri" type="xsd:string"/>
<xsd:attribute name="id" type="xsd:string"/>  
    <xsd:attribute name="projectUri" type="xsd:string"/>  
       <xsd:element name="fieldname" type="xsd:string"/>
       <xsd:element name="oldvalue" type="xsd:string"/>
       <xsd:element name="newvalue" type="xsd:string"/>
<xsd:simpleType name="StatusType">
  <xsd:restriction base="xsd:string" >    <xsd:enumeration value="Active" />
    <xsd:enumeration value="Resolved" />
    <xsd:enumeration value="Closed" />
 <xsd:element name="DefectChangedEvent" type="tns:DefectChangedEventType"/>

The following table shows a simple example of a Defect event:






The system goes into an infinite loop when you create a cycle of dependencies









9/5/03 11:03:33 AM

<changes> list



<oldvalue> Sometimes it just stops responding</oldvalue>


Steps to reproduce:

Have object A point to object B.

Have object B point to object A.

Click "search".

The system stops responding.


The allowed values for Int fields are persisted by the source Visual Studio Team System application, and are specified in the XSD file at implementation time.

Creating the XSD Schema File

Create the schema by using the XSD tool, which is a part of the Windows Software Development Kit (SDK). Example:

xsd.exe myAssembly.dll /type:MyNamespace.MyEventType /namespace:

For testing, an XSD file can be put into the Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\v1.0\Transforms directory on the application tier. The file name should be the same name as the event (without the namespace), followed by the extension .xsd. After updating the event schema file, use iisreset to propagate the changes.

See Also


Eventing Service

Eventing Service Architecture

Subscribing to TFS Events

Filtering Team Foundation Server Events

Formatting Team Foundation Server Notifications

Integrating a Web Service Notification Customer

Integrating with Team Foundation Server Security