Where to store connection strings for Custom Work Item Controls

Problem:

I need to store a connection string for a custom work item control.

Solution:

Store the connection string in a Team Foundation Server Global list.

Code:

The global list that needs to be imported into your Team Foundation Server

<GLOBALLISTS>
   <GLOBALLIST name="ConnectionStrings">
      <LISTITEM value="http://host/Vdir/WebService.svc" />
   </GLOBALLIST>
</GLOBALLISTS>

The field to add to your Work Item Type definition.

<FIELD type="String" name="ConnectionString" refname="DLB.ConnectionString">
   <ALLOWEDVALUES>
      <GLOBALLIST name="ConnectionStrings" />
   </ALLOWEDVALUES>
</FIELD>

Code for accessing the connection string in your Custom Work Item Control.

protected string ConnectionString
{
   get { return ((WorkItem)WorkItemDataSource).Fields["DLB.ConnectionString"].AllowedValues[0]; }
}

Explanation:

On a recent project I had to develop several Custom Work Item controls for Team Foundation Server. A couple of the controls made calls to a web service to retrieve the data to display.  The problem I needed to solve was where is the best place to store the connection string for the web service so it can be updated easily and simple to access from the Custom Control.  The idea I came up with is to store the  connection string in a Team Foundation Server global list.

Global list can be administered using the glexport and glimport commands and also by power toys and third party tools.  By adding an additional field to the work item definition I can easily access the connection string from the WorkItemDataSource property of the IWorkItemControl interface implemented by my custom work item control.

There are three sections to this solution.  First the entry into the global list to store the connections strings.  The second is the field I added to the work item definition to ease accessing the values of the global list.  I am sure you can gain access to the global list in other ways but using the AllowedValues collection is very simple. The final step is casting the WorkItemDataSource to a WorkItem, and accessing the correct index of the AllowedValues collection of the field we added to the Work Item Type definition.

Comments (1) -

  • Hi Donovan,

    just read that you are having experience of building number of custom controls for TFS work item. i am exactly required to do the same. but being a newbie in tfs, its quite difficult task for me. i am required to create a custom control (dropdown) which would populate data from outside tfs (for example EmployeeID as value field, EmployeeName as display field). i would be glad if you can post sample code similar to such kind of custom control for tfs.

Add comment

Loading