How to execute code on a TFS server after user verification of code

Question

I am creating an integration system that needs to execute some kind of code on Team Foundation Server (2010+) when a user checks for some changes. I can schematically access the validation without problems, but I would like to know when new validations will be added. Ideally, I would like to receive a notification and receive verification data so that I can manipulate it and publish what I need for another API, but if the notification that a new verification is all that exists, that would be enough. Ideally, I could force tfs to call my own C # code on the same computer.

I have been browsing the Internet for the past 2 days, and I am firmly convinced that this is possible, however I cannot find any details on how to do this, and, frankly, I am running out of ideas about where to look. If anyone has ideas on where to start, or where to look, or ideally any such initial ideas, it would be very helpful.

I mainly worked at TFS Integration Tools, but the documents for this are still dubious at best. I found all the adapter’s existing source code (for cleaning, etc.), but I don’t see anything to run execution anywhere, because I suspect that they are more designed for one-way migration.

Answer 1

There are various ways in which you can do this:

• Team build. Using the TFS Build Server, you can create a Continuous Integration or Gated Checkin assembly. In the build workflow, you can respond to all the changes that you discovered. You can use the TFS client object model to capture the "Changes" object. This contains all the data you need. ALM Rangers wrote a detailed guide explaining how to extend and customize the build process to suit your needs.

• Verification Policy . By creating your own validation policy, you can run a preliminary code check on the client (inside Visual Studio). This policy can serve as an example of how to interact with pending changes.

• ISubscriber TFS Application Level Plugin. Already mentioned @ppejovic. The application-level plugin is installed on the TFS server and will be launched in the process. Since it is placed in the process, you can do quite a bit. Samples that affect work items and / or source control are the Merge Work Items handler , TFS Aggregator . You can also return to the client object model if necessary, as described here .

• SOAP API This is the predecessor of the ISubscriber interface. You can still use it, but you will have more power and efficiency from the ISubscriber solution.

• Client model of the object . You can always create a service or a scheduled task on a system that periodically connects to TFS to request a history since the last check. By simply storing a request for anything newer than the highest change set number that you have seen so far, you can get all the information you need without having to extend the TFS itself. You will look for the VersionControlServer class. The QueryHistory method is the one you will need to retrieve the change sets.

There will be a good Pluralsight course that guides you through some of these scenarios .

As with most of these elements, the documentation is not enough and tools like Red-Gate Reflector.NET or Jetbrains dotPeek are invaluable.