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
Comments
Anonymous
September 18, 2006
Nice one! I was just about to do a similar thing and you've saved me a tonne of time.
On of the things to watch out for when doing this type of application is handling machine crashes. As you know, If you don't tidy up the subscriptions properly then the server will log plenty of errors to the event log. I know you have the unsubscribe code in your finally statement, but a tactic I like to follow is to query for subscriptions on start up and remove any if they exist before creating them again. (especially when the subscription code is running on a machine that may loose its network connection or not be attached to a UPS...)
Anyway - good job! Thanks for sharing.Anonymous
September 19, 2006
Grant Holliday on OzTFS.com Launched.
Buck Hodges on VC API: CheckIn() may return 0.
Martin Woodward...Anonymous
January 26, 2007
Team Foundation Server provides an event notification mechanism via SOAP or email delivery. My post belowAnonymous
February 06, 2007
I was collecting links & pointers to answer common questions in forums related to TFS eventing andAnonymous
March 08, 2009
PingBack from http://tune-up-pc.com/blog/?p=516Anonymous
September 22, 2009
Has anyone tried this with TFS2008? I noticed the post date of 2006 and was wondering if the SOAP response was still formatted the same.