We’ve all been there. You’re trying to debug a problem in your code and you step over a line only to realise that that’s the line where it all goes pear-shaped… the problem is that it’s a call to a method that isn’t your code, and you don’t know why it’s misbehaving. Curses. You could get the debugger to disassemble the method for you, but let’s face it, unless you spend a lot of your time looking at assembler or IL, it’s pretty intimidating, and hard to understand.
So what are you going to do?
Most of the time this is where I fire up Reflector, drill down to the offending method, decompile it and try to figure out what on earth is happening. And of course, if you can figure out how to use it, there’s Deblector (http://www.codeplex.com/deblector).
Often Reflector’s a big help, at least in pinpointing the rough areas where things might be going wrong, but what if you could debug into decompiled source code—in a language of your choosing—in Visual Studio? What if you could step through the code, set up breakpoints and watches, and see the values of member and local variables just the way you can with your own source code?
That might change the game quite a lot and so this is exactly what we’ve been experimenting with for the past few weeks. Take a look at figure 1 for an example showing some decompiled C# being stepped through in the Visual Studio debugger.
Figure 1. I can’t tell you how many times this would have come in useful over the years, and frankly I don’t like to think about it because it makes me cry and turn to strong liquor for comfort. Here I’m stepping through a decompiled, and as you can see obfuscated, method in the custom thread pool implementation in one of our shared libraries—this method validates the types of the parameters that will be passed in when the delegate is invoked. At the moment there’s no local or member variable information unfortunately.
Another great scenario for using this is one of those bugs which only occurs on release builds installed on your production system. Yep, you know what I mean, the kind of bug that you can never, ever reproduce on your development box, no matter what you do. The kind that results in you inserting 50 bazillion logging statements into your application to try to figure out what the hell is going on, and has you trapped in the office, or on the phone to an irate customer, when you really should be out chasing girls, or spending time with your family, or playing WoW, or whatever it is that very definitely isn’t trying to track down some obscure problem in a sweaty cubicle at 10.30 in the evening.
But I’m getting ahead of myself here because this isn’t even close to being ready for prime time—in fact I wouldn’t even think of putting it out as an early access build at the moment. It really is the earliest of prototypes, but if we can get it working reliably, and without it taking Visual Studio down every 5 minutes, this is absolutely something we’d like to release more widely a few months down the line.
A few points about it:
- We’d like to support Visual Studio 2005, 2008, and, when it arrives, VS10. We won’t support earlier versions and, if it proves too problematic, we may drop support for VS 2005.
- Heavily obfuscated code is likely to cause some weird results, or even decompilation failures, as we see in the bug reports we receive at the moment, and whilst we’re looking to improve this situation, perfection seems like an unlikely goal
- We’d like to provide all the standard debugger functionality: stepping, breakpoints, including conditional breakpoints, values of member variables, local variables, and parameters, watches, etc.
- Obviously edit and continue is a no-no, at least in the decompiled code. Well, it’s probably a no-no, and I’m not sure of the value of supporting it anyway. One reason it wouldn’t work is that the decompiled code may not be a perfect representation of the IL and, in fact, may not be compilable in all cases. From a debugging point of view this won’t matter most of the time.
- I don’t have any firm timescales. One of the main reasons for this is that our agenda is very much being set by the release of CLR 4.0, hopefully later this year, and we need to ensure that .NET Reflector supports this, as we do with our other tools. We also need to factor in some time for dealing with Windows 7. As soon as I’m able to be more definite about this I’ll let you know.
The most important point, for some of you, is that this will be a paid for product. I doubt this will surprise too many people and I’m sure it will annoy a few, but, you know, we have to eat. .NET Reflector itself will remain free, and much of the additional work for the new tool, such as adding CLR 4.0 support, and enhancing the decompilation functionality, will filter down into the free version, so it’s good all round. I am nevertheless braced for a barrage of vitriol and cynicism, but as long as I have a roof over my head you can call me what you want.
If you’re on a tighter budget you can still get some of this functionality with using the free add-ins, such as Deblector (http://www.codeplex.com/deblector), along with Jamie Cansdale’s .NET Reflector Visual Studio add-in (http://www.codeproject.com/KB/macros/reflectoraddin.aspx). I suspect the convenience of our new tool, due to its tight integration with the Visual Studio debugger, will mean that it quickly pays for itself for many of you though.
This is a great time for you to speak up about this, and to tell us more about the tool requirements you have in your development process. If you use Reflector, and you’re a working software developer, or software development forms part of your job, which is probably most of you, we’d love to hear from you. Please take a couple of minutes to complete our survey:
https://www.surveymk.com/s.aspx?sm=ncpu2RsUQAux0izSb_2fkABA_3d_3d
This should take no more than five minutes, and you’ll be entered into a prize draw to win one of five $50 Amazon vouchers.
That’s all for now!