I've been working on the #Develop debugger addin so that it can use the latest functionality that I've added to my library. I'm really impressed with #Develop as an application, and the flexibility that the plug-in mechanism has is quite amazing. Implementing a whole debugger as an add-in should be a really hard job, but so far integrating my code has been very easy. The source view is going to need some changes to the actual #Develop code if the plug-in is going to provide a fully integrated debugging experience but as far as I can tell it's only for a couple of features.
As far as the debugger goes I've nearly got the source code being displayed, but I'm taking some time as I implement it to get my head totally around the APIs that I'm using. I think I understand the debugger API now, but I'm still exploring the symbol API which is the important one for code coverage. I'm really going to have to do some tests with code coverage soon because I think that it's going to be a simple case of recording while sequence points are hit, and which instructions inbetween are hit so that I have partial coverage information, and then display this information to the user. What could be simpler? The hardest part will be ensuring that all of the code that's actually in the assembly that's being measured is recognised, but that shouldn't be too hard either. OK, I lied. As always presenting the results to the user in a useful way is the hardest part and that will take much longer than the actual metrics gathering to write.
What other blogs are saying about this post.
11:01:26 PM
|
|