Introducing .NET Reflector

I gave a presentation on .NET Reflector at the January 12 meeting of RockNUG.  I took most of my time demonstrating the product and answering questions, so I had very few slides.  So instead of simply posting them here and calling it a day, this blog post will incorporate some of the Q & A that happened during the presentation.

What Is It?

The title slide in my presentation called .NET Reflector an “x-ray machine for (unobfuscated) .NET assemblies”.  That little phrase actually understates what .NET Reflector can do.  Decompiling .NET assemblies is only one of the three major things it does (and is probably the best-publicized of its capabilities).  This tool also provides an excellent class browser and static analysis capabilities.

Why Is It Helpful?

In addition to giving developers to see code for third-party assemblies when they don’t have access to their source files, it can be quite a useful learning tool for seeing what the compiler generates on-the-fly for the source code we write ourselves.

Demos

One of the first features I demonstrated was the ability of .NET Reflector to decompile an assembly into multiple .NET languages.  C# is the default, but VB.NET, Delphi, Oxygene, MC++, F#, and MSIL are the other target languages available out of the box.  Using the add-in architecture of .NET Reflector, one developer added limited support for decompilation to PowerShell (download the PowerShellLanguage.zip file).

Around this point in the presentation, someone asked if you could cut-and-paste decompiled source into a file.  Not only does it work, but with Denis Bauer’s Reflector FileDissassembler plug-in installed, you can decompile an entire assembly into its constituent source code files (though I suspect that Red Gate Software would prefer that you pay for .NET Reflector Pro to get this capability). 

I was also able to demonstrate the much-overlooked static analysis capabilities of .NET Reflector.  They enable developers to learn what code depends on particular methods, where they’re used, what code exposes them, and where they’re called.  It turns out that there’s a free plug-in which extends this capability even further.  The Dependency Structure Matrix (DSM) plug-in allows developers to generate and manipulate matrices for determining the level of complexity in a software architecture.  Considering that a full-featured tool with DSM capability like NDepend costs hundreds of dollars per seat license, even a fraction of those features from a free .NET Reflector plug-in are well worth the time to learn how to leverage.

More Q & A

When I showed that .NET Reflector pulled in source code comments in its display of disassembled code, one member of the audience pointed out (correctly) that this was only possible because the XML file containing the comments was co-located with the assembly.  When I tested the disassembly capability afterwards without the XML file present, the comments didn’t display.

There was also a question from the audience about how .NET Reflector compared with ILDASM (which ships with the .NET Framework).  The short answer is that ILDASM is far more limited by comparison.  It only decompiles to IL, it lacks the analysis capabilities of .NET Reflector, and most importantly it doesn’t have a plug-in architecture to enable expansion of what it can do.

Conclusion

My presentation on January 12 only scratched the surface of what .NET Reflector can do.  I hope this post has added more depth, and piqued your curiosity to use the tool to improve your own development experience.  You may find the following links helpful in leveraging .NET Reflector for your own development work: