Get history of file changes from TFS to implement custom "blame"-behaviour of exceptions

Question

I'm trying to make some way of figuring out who to "blame" when an exception is thrown in our application (at work). It could be me causing it of course but I can accept that :). But to do this I need the history of a file in TFS so I can check who last made a change at the line of the exception. Its of course not always at the row of the exception that the erroneous change was inserted, so I would probably also need to check any changes to the same file and lastly any check-ins made very recently. I'm not sure how I will work out this but I would like to check with the community first if there is any already existing solutions for this? I have no experience with the TFS API yet so I have no way of telling whats possible and whats not. I guess I would integrate this into our app in the unhandled exceptions-handler. When some candidates of the exception is found I need to inform them by email. In the process it would be nice to log how many times a certain exception has been thrown by any user on our intranet, who, when, how etc. It could save us a lot of time (and money).

Answer 1

I like the spirit! The TFS API is very powerful and you can go to any level of depth for the information you are interested in.

• You could create an App, lets call your app TFS API app, check out how you can connect to TFS programmatically http://geekswithblogs.net/TarunArora/archive/2011/06/18/tfs-2010-sdk-connecting-to-tfs-2010-programmaticallyndashpart-1.aspx.

• The TFS API allows you to Query TFS for all changes (Changesets) made to a file. So, lets say, ClassAbc.cs raises an exception, if you have an event bus that raises this exception to your TFS API application, you can use the method in the versionControlService GetChangeset method to get all changesets performed on that file. Check out how to do that here http://geekswithblogs.net/TarunArora/archive/2011/06/26/tfs-2010-sdk-smart-merge-programmatically-create-your-own-merge.aspx.

• At this point you could do a delta between the 2 changesets and get the code changes using something like this.

  public static void GetMergeDetailsForChangeSet()
  {
      var tfs = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("Enter the url of team project"));
      var versionControl = tfs.GetService<VersionControlServer>();
  
  
      var a = versionControl.GetChangeset(12322);
  
      VersionSpec changeSpec = new ChangesetVersionSpec(a.Changes[0].Item.ChangesetId);
  
      var abc = a.Changes[0].Item.VersionControlServer.QueryMergesWithDetails(
          null,
          null,
          0,
          a.Changes[0].Item.ServerItem,
          changeSpec,
          a.Changes[0].Item.DeletionId,
          changeSpec,
          changeSpec,
          RecursionType.Full);
  
  }
  

• Now that you would have the actual code, you can run a set of StyleCop http://www.codeproject.com/KB/cs/StyleCop.aspx rules against that code block and on finding possible exceptions or general code analysis results could be recorded in a database and emailed to the user.

Sounds interesting. But, alternatively, you could use the Annote feature in TFS to see the series of changes done by a developer on a file and associate code analysis to your CI build defination and get constant feedback on code changes done by the developers in your team.

Answer 2

Does this really make sense? Consider in how much scenarios an exception is caused by a change at the point it is thrown. Usually the reason for the exception is somewhere up or not even within the callstack at the time of the throw. You should not invest time in something that will not help you in 99% of the scenarios.