Lutz Roeder handed over responsibility for development of .NET Reflector to Red Gate nearly eighteen months ago. "What's been happening since then?", one might ask. The answer is "Rather a lot," as we found out when we sent Bob Cramblitt to the .NET team, also known as the "Managed Heap," to find out.

"It lets you get
 right into the guts
of everything your
 application is doing,
 even if you don't
have the source code."

After taking over development of .NET Reflector in August 2008, Red Gate has been working on two fronts simultaneously: adding new functionality and fixing bugs for the free, community version of .NET Reflector, and developing a new debugging tool called .NET Reflector Pro.

Bob Cramblitt talked to three members of the project team – Bart Read, project manager, and developers Clive Tong and Alex Davies – to find out more about the philosophy and work behind the new releases.

---

BC:

First things first: What's new in the latest version of .NET Reflector?

BR:

We fixed a load of bugs, improved usability and added support for .NET 4 assemblies.

AD:

And, you can now jump to a class or method in .NET Reflector directly from your code in Visual Studio. I wrote about this in a bit more detail in my blog at http://www.simple-talk.com/community/blogs/alex/archive/2010/01/20/87639.aspx.

BC:

There's naturally been a lot of talk about the decision to develop a paid tool, called .NET Reflector Pro, that uses Reflector technology.  Could you describe .NET Reflector Pro?

AD:

It lets you debug third-party code even if you don't have the source code for it. It decompiles the assembly to either C# or VB code, and lets you step through it in Visual Studio, just as you would do with your own code. This is all controlled from a Visual Studio add-in, so you don't need to leave your coding environment.

BR:

It lets you get right into the guts of everything your application is doing, even if you don't have the source code. If you like snappy taglines, it's "The white-box debugging tool for .NET developers" or "An MRI scanner for your .NET code."

BC:

.NET Reflector Pro is $195. Do you think it's worth the price?

CT:

Yes, it's a bargain for what it gives users. It offers some unique features for helping you understand code that you didn't write.  It is an extension to Reflector, offering functionality that is currently not available either from the freely available version or from any of the freely available add-ins.

BR:

Yes, of course I do! Seriously, the community will be the judge of its value, but early comments are overwhelmingly positive.  .NET Reflector Pro allows you to more quickly build and ship higher-quality products, with fewer defects, at a lower cost. There are several reasons why it's worth the money:

• It allows you to interactively step right inside a component, see exactly what's going on, and have the full power and functionality of the Visual Studio debugger at your disposal.  This makes diagnosing problems much quicker and easier.
• It allows you to quickly and accurately understand the behavior of framework and third-party code, and zero in on the cause of problems.
• It allows you to avoid the tedious process of wetware debugging, where you decompile the code, read through it, and try to figure out what's going on. The interactivity means you gain insight and an understanding of the code that would be nearly impossible otherwise.
• All this means your development workflow is uninterrupted: there's no context-switching overhead. You don't have to step out of the debugger to fire up .NET Reflector. You can just carry right on with debugging.

In terms of the amount of time and effort it's going to save you, I'd say it's a bargain!

BC:

Fair enough, but what's the value of being able to see the code within a component or black box?

CT:

There are a few important reasons why a developer would want to do this:

• You might find that the component doesn't behave in the way you think it should, and want to figure out the right way to use it to get the desired effect.
• Often the documentation doesn't go into the detail that you need.  The component might raise events, for example, but the order of those events might not be specified, nor are the exact actions you are allowed to take inside the event-handling code.
• Besides, developers are the kind of people who like to know how a component does its stuff, either because they are interested in the algorithm it uses, or because they want to check that the component won't do anything silly that will kill their performance.
  

With .NET Reflector Pro you can step through code line by line, and decide whether you want to go inside sub-functions. You can look at the local variables, modify them and move the next statement pointer to allow you to see how the code will deal with a certain situation. You can dramatically increase your understanding of how code works.

BC:

How did Red Gate decide on the functionality for .NET Reflector Pro?

BR:

Well, we spent time doing research work, getting lots of user feedback, and doing technical prototyping to see if what we were planning to do was feasible. We also floated the idea and the results of the prototyping in a Simple-Talk article: http://www.simple-talk.com/community/blogs/bart/archive/2009/03/23/72559.aspx. The article got thousands of hits in a very short time and generated positive comments, so we thought "What the heck, let's just go for it!"

We also wanted to give something to users of the free version of .NET Reflector in the Visual Studio integration, so we've added the "Open in Reflector" functionality to the add-in. We would like to do more with this in the future but, for this release, we've had to concentrate on the debugging functionality, which turned out to be trickier than we originally anticipated.

BC:

Is there anything special about the user interface or methodology?

BR:

The most noteworthy thing is that there isn't much of it. The user interface is the Visual Studio debugger. We wanted to provide as seamless an experience as we possibly could within Visual Studio, so we've tried to stay behind the scenes. The assembly selection, regeneration and decompilation reporting are the only pieces of UI that aren't already part of Visual Studio.

AD:

It's really simple.  It's just a Visual Studio add-in, so you launch it from a menu in VS. You pick the third-party assemblies or the executable you would like to decompile.  You can then treat the decompiled code like your own: you can step into it, set breakpoints, inspect and modify variables, and use all the debugging techniques you would use on live code.

Rather than having a static view of the code, as in .NET Reflector, you can now follow the code as it does its stuff, to understand what it's doing and try to narrow down on the bugs in the application.

BC:

Can you tell us a bit about the process used to develop .NET Reflector Pro?

BR:

Sure. Before the project was even given the green light, we did usability tests on several iterations of the designs. Once we began working in earnest, we provided users with early builds of the product. We got a lot of feedback, and started remote usability sessions, which meant we could quickly discover problems with the application and get them fixed early on.

CT:

We've had three developers, one tester, and one product manager working on this at various stages, using agile processes. We did 13 sprints of roughly two weeks each. In summary, three people for six or seven months.

BC:

What comes after this?

BR:

Alcohol. Lots of alcohol. Followed by a monumental hangover.  Then, it's on to the next versions. We're going to add support for the new C# and Visual Basic language extensions in .NET 4.0, for example, adding support for the dynamic type. There'll also be more bug fixing on the free tool.