If you’ve ever been coded into a corner and bailed out by Reflector then you’ll love it forever after. I do not know why anyone would not love it. It is the perfect tool all by itself, and if Reflector can’t do it, you can easily add the functionality through its extensive customization points. There are existing add-ins available to help with a large variety of tasks.

It’s perfect, so why do we need a new version?

Well it wasn’t exactly perfect. There is always room for improvement, and ongoing maintenance is important.  Every application has bugs, .NET gets revised, and the quality of Reflector’s decompilation can always be improved. Red Gate makes a great partner, promising to stay true to the spirit of Reflector. This is an important piece not to break.

As you look at the new version of Reflector, one of the first things that you will notice is that it looks just like Reflector 5. The look is so similar that you can easily forget which version you are in, but there are some easy ways to tell the difference. If you have ever used Reflector before, you will immediately be comfortable with the new version. All the changes were under the cover.

If you have ever used the debugger in Visual Studio you will immediately be comfortable with the new functionality in the ‘Reflector Pro’ add-in.

So What Is All the Excitement About

It turns out that there are actually three components to this new version. We have the stand alone application that we all know and love, a Visual Studio add-in, and Reflector Pro. Reflector Pro requires a license but the other two components remain free.

Without a doubt, the most exciting thing about the new version is the integration with Visual Studio. The plugin for Visual Studio is installed automatically the first time you launch Reflector. If you want to remove the plugin later, you can always access the Integration Options window from the tools menu.

The integration options window showcases another feature that has existed for some time, but was not very well known. In earlier versions of Reflector, you could “register” Reflector to enable integration with Windows Explorer. This integration allows you to browse Assemblies directly from Windows Explorer. This is a very convenient, but underused feature. If you did not enable this integration, you missed out on the context menu. Now this integration is automatically enabled. While this is old news, if you never knew about, it can be a time saver.

Of course the whole of integrating with Visual Studio is to use the debugger which is where Reflector Pro comes in.

Debugging Will Never Be the Same.

The add-in for Visual Studio is free, and allows you to use reflector from within Visual Studio, but there is extra functionality in there called Reflector Pro. The coolest thing that you can do with  Reflector Pro is to debug code for which you do not have the source code, or even the debug symbols. This extra premium functionality allows you to specify any referenced assembly for Reflector to handle, allowing you to debug. Reflector will decompile the Assemblies that you specify and then allow you to step into those Assemblies as if they were part of your solution.

Now this won’t work for Assemblies that have been obfuscated, but, if you can browse an Assembly with Reflector, you can step through it with this add-in. There is another caveat. If you already have the PDB for an Assembly, Reflector will not decompile the Assembly and overwrite the debug symbols, but Reflector will give you the option to remove or rename the PDB file yourself.

Once you have selected the Assemblies that you are interested in and Reflector has worked its magic, the fun is ready to begin.

When you step into a method from one of the Assemblies that you selected, Reflector will present a file with the full code for the containing type. This is the same code that you would have seen in Reflector by browsing to that Type. As far as Visual Studio is concerned, this is just like any type in any of the classes that are already in your solution. You can use every debugging feature that Visual Studio has to offer.

Here we are stepping through the code for the Equals on a string. We can set the values of variables. We can rewind code within a method. We can set breakpoints, step into, step out of, add watches, etc.

There are few limits for a developer with source code and a debugger. Now this control extends to the DotNet framework itself!

What Can We Do With This?

This is as revolutionary as the initial release of Reflector.  When Reflector was first released, developers could for the first time ever pull back the covers on framework Assemblies and see what was happening. For many of us, this was a huge step forward in understanding just how the pieces of the framework fit together. Reflector Pro takes just as big of a step forward. Now not only do we have a static image of what the code looks like, we have a sand box where we can play and truly understand what is going on.

Reflector Pro allows you to set and reset configuration settings on the fly to truly understand connection pooling. Have you been burned with a third party web control not treating ViewState properly? Now you can set breakpoints within the control and add Watches in order to completely understand where the problem lies.

Have you ever struggled to reproduce the Production environment on your workstation to troubleshoot a Production issue? Sometimes, Production may be running one version; QA could be testing a different version; and yet a third version is active in development. It is a difficult, time-consuming, talk to Extract the correct versions from source control and recreate the source code base in order to reproduce the version in Production: After all that effort, there is still a chance that you have not fully reproduced the production environment. Now, as long as you have the Assemblies that are being used in Production, you can exactly reproduce the Production environment and step through Production code without having to invade the Production environment.

Do you ever need to track down problems in your own GACed components? How many times have you wished you could step into the code for one of the application blocks in the Enterprise Libraries? How many projects are in your solutions just to simplify stepping through them with a debugger even though they are not likely to change?

The possibilities are limited only by your imagination!

I have reached for this many times throughout the beta period. It quickly became second nature to step into Third Party controls and to forget about the distinction between framework code and application code. I even discovered new nuances to architecture components that had remained static and stable for over a year. Problem areas can come to light in code that you wrote, but never think about because it has not changed or caused any visible problems recently.

A Word about the Developers

I spoke earlier about the importance of staying true to the original vision and spirit of reflector. This shines through in the developers and methodologies followed through the beta process for this new version of Reflector. I do not know how many developers actually worked on this project, but I know two developers who diligently followed and responded to every post in the support forum.

Alex and Clive took every post seriously and responded to every post. Sometimes they offered reasonable explanations for unexpected behavior, sometimes they offered practical workarounds for known issues, and more often than not they changed code based on the feedback of developers who downloaded their app and ran it through its paces.

These guys were genuinely excited when a new bug was found whether it was reported on the forum or identified in a usability test, they took it seriously and provided feedback as each bug was explored and resolved.

This dedication and professionalism is what it takes for a pivotal tool like Reflector to go from being the brain child of a lone individual to the product offering of a company like Red Gate.

Changes to Reflector

Some of the less glamorous but equally important changes to Reflector may not get as much attention, but they are still important. There were several places where the de compilation back to C# and VB simply returned strange results. Granted these generally involved more complex code structures to begin with, but there are now very few places where the de compilation will have to revert to goto.

In the past Reflector used a home grown obfuscation process. This sometimes led to several problems, specifically when trying to develop plugins. Reflector now uses SmartAssembly for obfuscation. This conversion created several complications as evidence through the posts in the support forum, but in the end, this will improve performance and stability.

Reflector is wonderful but it was not always known for having the best memory management. I have often seen Reflector eat up a tremendous amount of memory. Most of the memory hogs stem from some of the plugins and so will continue to have memory issues, but the memory management future for Reflector is in good hands with the friendly folks at Red Gate.

Summary

.NET Reflector seems to be in good hands.

When Red-Gate took on .NET Reflector, many people were worried about its future. But fortunately, Red Gate thought it best to keep the core application free with a simple clean interface, just as Lutz Roeder, the original designer, intended. They have restricted their commercial activity to supplying a new add-in that provided additional functionality, but would require the user to purchase a license to access it.

Of course this works as a strategy only if the add-in gives the purchaser a huge saving in time and an increase in code-reliability. Reflector Pro fits this model. I can’t imagine going back to coding in .NET without Reflector Pro.