Click here to monitor SSC

Software Engineer - Red Gate Software

A new Visual Studio hosted debugging technology based on .NET Reflector

Published 22 March 2009 8:00 pm

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!

18 Responses to “A new Visual Studio hosted debugging technology based on .NET Reflector”

  1. odalet says:

    Seems really interesting! Hope you manage to deliver this quickly (and at an affordable price ;-)

  2. webooth says:

    “I doubt this will surprise too many people……”

    Truer words were never spoken.

  3. EvilJ says:

    I think this is a great idea and would be a very useful tool. I find myself using Reflector a lot (more than I would prefer) and it is one of the top-three tools in my toolbox. If this app becomes a reality, I would definitely add it to my arsenal.

    The paid-for status, as you said, isn’t surprising… And I wouldn’t expect you guys to give it away. Most the people that will skewer you for charging for an app like this would be using it on for-profit projects anyway. So let the snow-white programmer that has never charged for his work be the first one to throw a stone… Everyone else should just keep quiet. Like you said, we’ve all got to eat. If you deliver on functionality and price, I’ve got to imagine you’ll sell the crap out of this.

  4. danielearwicker says:

    This sounds absolutely perfect, and well worth paying something for. (To those tempted to complain – look, the functional spec is finished, all you have to do now is implement it in your spare time and give it away for free.)

  5. webooth says:

    EvilJ; Everyone else should just keep quiet….
    That’s a nice attitude. It goes without question that you have donated for any open source used in your “arsenal”.

    I think this announcement should be viewed in the light of the original announcement that Red Gate was taking over Reflector and the subsequent comments. It’s all been said there and this is just documentation of everyone’s fears coming true. This is the equivalent of a “Pro” version and using some cleaver semantics to say it isn’t so they can charge for it.

  6. vavjeeva says:

    Excellent.. this would be much much useful for developers who works under corporate framework on top of dotnet framework.. i am waiting for this release..

  7. Anonymous says:

    Life as a developer at Red Gate has many opportunities! One moment you’re finishing off code in the…

  8. Anonymous says:

    Life as a developer at Red Gate has many opportunities! One moment you’re finishing off code in the…

  9. Anonymous says:

    If you’re read Bart or Clive’s blog recently, you might be as excited as I am about the next version…

Leave a Reply