How to execute code on TFS server after a user checks in code

Question

I'm building an integration system that needs to execute some code on a Team Foundation Server (2010+) server when a user checks in some changes. I can diagrammatically access check ins no problem, but I would like to know when new check ins are added. Ideally, I would like to be notified and given the check in data so I can manipulate it and post off what I need to a different API, but if a notice that a new check in is all that exists, that would be sufficient. Ideally, I would be able to have tfs execute a call to my own C# code on the same machine.

I've been looking around the internet for the last 2 days, and I'm firmly confident that this is possible, however I can't seem to find any details on how to do it, and frankly I'm running out of ideas on where to look. If anybody has any ideas on where to start, or where to look, or ideally any similar source ideas, it would be greatly appreciated.

Mainly, I've been digging around in the TFS Integration Tools, but the docs for that are still questionable at best. I've found all of the existing adapter source code (for clearcase etc) but don't see anything to trigger execution anywhere, as I suspect those are more meant for one way migration.

Answer 1

There are different ways you can approach this:

1. Team Build. By using a TFS Build Server you can create a Continuous Integration build or a Gated Checkin build. In the build workflow you can then respond to whatever changes you've detected. You can use the TFS Client Object Model to grab the Changeset object. That contains all the data you'll need. The ALM Rangers have written an extensive guide explaining how to extend and customize the build process to suit your needs.

2. Checkin Policy. By creating a custom checkin policy you can run code pre-checkin on the client (inside Visual Studio). This policy could serve as a sample on how to interact with the pending changes.

3. ISubscriber TFS Application Tier plugin. Already mentioned by @ppejovic. The Application Tier plugin is installed on the TFS server and will run in process. Since it's hosted in process, you can do quite a bit. Samples that act on Work items and/or Source Control are the Merge Work Items handler, the TFS Aggregator. You can also fall back to the Client Object Model if needed, as described here.

4. The SOAP API. This is the precursor to the ISubscriber interface. You can still use it, but you'll have more power and efficiency from the ISubscriber solution.

5. The Client Object Model. You can always create a service or a scheduled job on a system that periodically connects to TFS to request the history since the last time it checked. By simply storing querying everything newer than the highest changeset number you've seen so far you can get all the information you need without having to extend TFS itself. You'll be looking for the VersionControlServer class. The QueryHistory method is the one you'll need to fetch the changesets.

There's a nice Pluralsight course that takes you through some of these scenario's.

As with most of these items, documentation is scarce and tools like Red-Gate Reflector .NET or Jetbrains dotPeek are invaluable.