Debuggers

Implementing debuggers in .NET

There's a new debugging article coming

After a stupidly long wait there's a new debugger article on the way, and the first part should be posted early next week. The topic for the next few articles is how to create a coverage analysis tool that can handle applications written in any .NET language without using the profiling API. It'll still be targetted at .NET version 1.1, but I'll probably cover porting it to 2.0 when the 1.1 version is complete. It's times like this that I love .NET as it makes doing this kind of thing terribly simple compared to the pain that it is under...

What's new in the .NET profiling API for version 2

There's an interesting article in msdn magazine about what's changed with the profiling API for version 2.0 of .NET. The quick summary for anybody maintaining code that uses the old version is that in process debugging has gone and been replaced with lots of ways of doing what you were doing before. Time to play with the changes.

I'm getting dangerously close to being motivated again

Well I had a few weeks off work and there was a monent when I was walking through the woods when I realised that I had found my motivation for coding again. I had lost it recently due to a mix of work and the current far future gazing that lots of the blogshere has been concentrating on for the last year or so. I'd like to see more people concentrate on the now, and not on what's coming from the latest beta programmes and so I decided to try and keep the information moving for what we have now. I've started working on the...

I've posted my new debugger article

I've posted my new debugger article here. This is another one that started out bigger and got simpler and simpler as I worked through it as I realised that all of the difficult concepts and code for creating debuggers is actually handled in part 3. In fact it's so simple I haven't even bothered with the sample application because it just made it look more complex than it really was, although that code is still going to be released as a little utility once I'm happy with it's functionality.

I've moved my debugger articles

My debugger articles are now hosted under .TEXT here, which means they now have comments enabled so get commenting. Next one up later today. Probably.

Why are the hard bits of a program always the easiest to write?

Writing a code coverage analysis tool: Easy Making meaningful html based output with colourised text: Harder Surely they should be the other way around? Escaping invalid characters from xhtml is harder than you would think when you have to preserve the original lines and columns as well so you can apply the formatting. At the moment I have a hideous algorithm that works backwards through the file inserting tags and calling HttpUtility.HtmlEncode on the rest of the text. At this point I'm very glad that I decided that I should do this properly and unit test using TDD because this algorithm is...

When example code gets out of control

The example code for my next article seems to have a life of it's own. It started off as a simple bit of code, then I decided to be more fancy and make it do something useful. After I made that decision I decided that it was the right time to add my wrapper because it opened up the possibilities for the example code becoming more powerful in the future. Now I'm at the stage of wanting to release the example code as a fully fledged application along side the article on how it works. I have the application working except...

Getting the name of a class

One of the interesting things about the CLR's debugging API is that it's not as totally OO as it could be because implementation gets in the way of design. An example for this is there is no GetName member for ICorDebugClass because this needs to be performed by using other objects. One of the reasons why I'm implementing a wrapper around these APIs is to pull this information together and so today I implemented a Name property on the class object. The function that returns the class name is IMetaDataImport::GetTypeDefProps and so my wrapper function is just a basic call to...

Why am I writing a wrapper around the debugging APIs

People seem to want to comment on this blog more than the last one, and in my last post it was pointed out that you don't need to use a wrapper assembly on the debugging APIs because you can just import the type library and go from there. There are reasons why I'm using a wrapper over the COM interop method. The first was that the type library contained things that needed modifying the last time I looked in order to make it correct (which was, admittedly, a long time ago and a different version). The main reason, though,  is...