Extending Work Item Tracking by Using the Client Object Model for Team Foundation
You can programmatically create, change, and find bugs, tasks, and other types of work items by using the object model for tracking work items. To access work items, you must first connect to Visual Studio Team Foundation Server, as described in Connect to Team Foundation Server from a Console Application.
Common Tasks
Create a Work Item By Using the Client Object Model for Team Foundation
Edit and Save Work Items by Using the Client Object Model for Team Foundation
Query for Bugs, Tasks, and Other Work Items
(Code Gallery) Enumerate Stored Queries
(CodePlex) Custom Controls for TFS Work Item Tracking
Writing Code for Different Types of Work Items by Using the Client Object Model for Team Foundation
Threading Considerations
If your application is multithreaded, it should create a WorkItemStore for each thread. If the threads share a WorkItemStore, the application will not scale well. As long as the WorkItemStore and related objects are processing, all other threads that share the WorkItemStore will be blocked.
The cost of initializing a WorkItemStore is significant. Therefore, you should initialize the object and hold a reference to it for the life of the thread. For example, if you use the object model for tracking work items in an ASP.NET application, you should cache the WorkItemStore object in the user session or create a thread pool and use a single WorkItemStore object for each thread.
Metadata
The work item database contains a set of metadata that describes the types of work items, fields, rules, forms, and other information about how types of work items are configured and used in each team project. A WorkItemStore obtains and uses a local cache of that metadata. The metadata is changed whenever any one of these elements is updated. For example, if a value is added to the list of allowed values for a field, another version of the metadata is created. The client object model for tracking work items verifies that your WorkItemStore is using the most recent version of the metadata. The system performs this verification whenever you call a method that results in a round trip to the server, such as WorkItemStore.Query or WorkItem.Save. If there is a more recent version of the metadata, the system obtains the updated metadata and then raises the WorkItemStore.MetadataChanged event.
If your code is affected by changing metadata, your code must respond to this event. For example, code that displays the work item form must respond to this event so that the most recent version of the form appears.
Your code can prompt its instance of WorkItemStore to check for an update to the local metadata cache by calling WorkItemStore.SyncToCache. For example, if your application uses multiple WorkItemStore objects, when it receives a WorkItemStore.MetadataChanged event, your code can use WorkItemStore.SyncToCache to prompt the WorkItemStore objects to use the updated version of the metadata cache.
Your code can prompt its instance of a WorkItemStore to check the server for updated metadata by calling WorkItemStore.RefreshCache.
Additional Resources
(Code Gallery) WorkItem Samples
Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore