As I read about automated error reporting by Laila Lotfi’s article over at Red Gate’s Simple Talk community site, I first thought yeah nice that’s what we need in good software. But on a second thought I considered that it was not going far enough.

Truly having automated error reporting is quite well but having hundreds or thousands of error’s (depending on the amount of sold licenses) depending on same issues is not what I’d like to see and sorting duplicates out is like a job for someone who killed mom and dad. For a second reason much of a developers live and development process is guided by ticket system (You can find some good comparison regarding issue-tracking systems at wikipedia.org). So why not integrated automated error reporting into a consolidating service (which does that ugly sort and compare job) and let it publish new issues to a ticket system?

Might not be the best solution in town but sounds even better than nothing - right? Next up here is a small image showing up how it could be done:

automated error reporting schema

  1. So our application reports its unhandled exceptions to the consolidation service (named AER service) which stores the exception report in it’s storage. I find it reasonable to store all reported exceptions in a storage (even for those issues which are already reported) because it gives the developer even more scenarios (assuming the exception report contains detailed informations about environment and current stack…) under which circumstances this error appears.
  2. After storing the report it crawls the bugtracker to find a similar issue, if it doesn’t it creates a new entry containing necessary informations and even a sort of link to the reports in the storage so that the responsible developer can find additional infos for the exception.

That said I will try to post a little series about reaching this end-scenario. The tools and libraries I choose to achieve this goal are based on the facts that I owned licenses of them already - but I guess it is even achievable with others.

So what I have is:

  1. Red Gate’s SmartAssembly 5: this tool does already a nifty job for automated error reporting. To be honest you will need the PRO version to reach the finish line in this scenario, while that is the version which gives you access to the SDK and a self-hosted custom web-service. (You can read about its detailed features and why I chose to give it a shot for automated error reporting here and here)
  2. JetBrain’s YouTrack - as they say the fastest issue and bug-tracker. This isn’t much the reason why ;-) - I have it so I use it - it has a REST API so I think I can even link it into the set goal.

What do I need (which seems to be not so much at least):

  1. an interface to YouTrack - REST based!
  2. a synchronisation job which is called after an exception gets reported - to decide if an issue has to be created and does so via the mentioned REST based client

First I thought:

This seems to be very pleasant and causing not very much work

But the problems I were facing are:

  1. There is already a C# YouTrack REST client - named YouTrackSharp written by the famous @ hhariri - the JetBrains guru itself. Sadly it is an implementation which uses the JSON API of YouTrack - which is really really broken - so I did not get managed to hook some attachment support in it. Maybe another reason is that I do not know very much about JSONFx which is used in there, too. And the lack of documentation doesn’t made it easier for me. So I decided to build up my own REST client for YouTrack - based on the XML REST API using RestSharp which I know pretty well. I named it RestTrack. It isn’t 100% finished yet - but it does all I need to create issues, search them, create attachments and so on… I will release the source in near future. As said it isn’t such as good as YouTrackSharp (which uses .NET 4 dynamics already) - it’s more the old-school way using XML-Attributes but it fits my needs :-)
  2. My second problem was/is that the SmartAssembly documentation in this case is a bit - let’s say - lean. So I have to trouble the support really a lot. But they are as always good and gave me lot of stuff at the hand - thanks for that!

Covering the basics here you can expect in the next post some code stuff about RestTrack and how it can be used to search, create and attach files to issues.

Stay tuned… and as always: suggestions are pretty well appreciated!