The Debugger Extension, Part 2: A Use Case & The Problem Setup
November 23rd, 2005
Now that we have a feel for the difficulty of the task, we should probably stop for a moment and reflect. Do we really want to go through with this?
Why would you want to go to all the trouble of writing your own extension? Especially with the SOS extension around, this may seem like an awful lot of effort if you are working with managed code. I would tend to agree, but I have found a few situations where writing an extension was helpful.
The best example I have revolves around a centralized framework for accessing the ASP.NET Cache in a web application, which I authored and which my company is currently using. Each cached item is accompanied by our own metadata. Writing an extension that understood this structure and was able to aggregate cache statistics made it easier to analyze dumps of high-memory situations when thousands of these objects are present. I can only offer my own experience here, but I’m sure many developers have similar functionality.
I think that the arguments for writing an extension become more compelling once you have developed a certain amount of your own framework for doing so (I will try to share some of mine here). It is also a very instructive activity—you can learn a great deal about the way the CLR works by getting your hands dirty.
Now that I’ve hopefully convinced you that this will be a worthwhile activity, let’s come up with a very stupid piece of C# code to study.
enum Colors : int
{
Red = 0,
Green = 1,
Blue = 2,
Purple = 3
}
class ArbitraryType
{
private Colors _color;
private int _id;
public ArbitraryType(Colors c, int id)
{
_color = c;
_id = id;
}
}
Our job will be to print out statistics about the “Colors” of the ArbitraryTypes in memory.
Before we can do that, we will have to do some investigation so that we understand exactly what we’re looking for. That will be the subject of the next post.
