Subscribing to TFS notifications without implementing a client Web Service

First, I want to say thanks to all of you who responded and provided feedback about the check-in policy pack (see previous blog post). We got a great amount of feedback- both here and by email- and we will continue the march forward with the idea of releasing a pack in the near future. Once again, thanks.

Today I have another opportunistic post and this one comes from one of our developers: Vasu Sankaran. He previously worked in Version Control and is now helping our efforts in performance and limit testing.

As you already know, Team Foundation Server provides an event notification mechanism for events such as checkins, work item state changes, build completion, etc. A subscriber can opt for email or SOAP notification for specific types of events; the preference is indicated at subscription time. Currently, only email subscriptions are available when using the UI. There are several posts that discuss the subscription to these alerts using the bissubscribe.exe tool, or programmatically through the Team Foundation Eventing web service (see, for example, https://blogs.msdn.com/narend/archive/2006/07/27/679571.aspx ).

Unfortunately, this method is sometimes not feasible for some of our customers and even for us internally. A part of our test automation usually runs on client machines that do not have the required installs to run a web service so we were required to come up with different ways to accomplish this.

The attached sample code demonstrates a subscription for SOAP notifications without requiring a web service on the client side. We set up a TCP listener bound to a port on the client, and specify this port as part of the delivery address when we subscribe. The code is well documented and easy to follow. Have fun!

Legal: This sample code snippet is governed by the MS-PL

 

TCP Event Subscription.cs