Encouraging .NET Reflector Add-ins

Jason Haley is well-known for the resources he's provided to developers who wish to extend Reflector's usefulness by writing Add-ins, so we decided to sit him down for a chat.

Jason Haley is one of the most active amongst the authors of Add-ins for .NET Reflector. He has provided four Add-ins; AssemblyCollection.Sort, Enums, CodeShortcut and OpenZip, and he’s currently at work on a .NET disassembler codenamed ‘Debris’. However, it’s for his help in explaining the add-in architecture, Presentations at Code Camps, providing resources on his website, and for his VSI Add-in Starter Kit for Visual Studio (the Reflector Add-in Starter Kit (C#)) that he is probably best known to .NET Reflector users. Together with his add-ins, which are provided in source, Jason’s site provides an excellent place to start writing an Add-in (Peli’s ‘Reflector Add-In Tutorial’, and other useful resources, are linked to). Jason also maintains pages on the related subjects of Code Obfuscation and ‘Reversing’, with links to a number of important resources.

Jason is a Senior Software engineer, MCSD .NET, who has been using NET since 2001. As well as his work on disassemblers, and Reflector, he also maintains one of the best Link Blogs around, based on a cornucopia of RSS feeds.

We caught up with Jason after the Seattle Code Camp and asked him a few questions about NET Reflector and his work on Add-ins…

How did you first come across Reflector? Why did you first find it useful?

When I started learning .NET I was determined to figure out how it all worked, and started using ILDasm sometime during the .NET beta 2 period. I honestly don’t remember where I first heard about Reflector, but when I started using it, I pretty much stopped using ILDasm. The way the Lutz hyperlinked all the items of an assembly to let you navigate the code like a web site was the killer app for me.

You’ve become better known for explaining how to extend Reflector than for the Addin extensions you’ve written. Is this because your addins are primarily designed as examples to illustrate how to write add-ins?

The addins I’ve written are mostly ‘fixes’ or small extensions to Reflector and not generally useful to most people – mainly due to their inspiration coming from a need I had at the time. The inspiration behind the addin articles was to show people that it really isn’t that hard to do, in the hopes that more people would write addins. I’m planning to write a few more articles when I finish up my Debris addin (on implementing languages – something I haven’t done yet).

Of all the Add-ins, which do you see as being the ten most useful for someone, a .NET Developer, who is new to .NET Reflector?


  • TestDriven.net (to make Reflector easier to get to from VS.Net)
  • Any browser or Loader fits their current needs, for example: SQL2005Browser and SilverlightLoader


  • CodeMetrics for getting a better sense of the state of your code
  • DependencyStructureMatrix is neat to see what you code depends on
  • Doubler to help get started on unit tests
  • CodeSearch for a nice searching option
  • Xmi4DotNet is nice to diagram assemblies in UML tools
  • PowerShellLanguage for people getting familiar with PowerShell
  • ReflectionEmitLanguage is good for people looking into the System.Reflection.Emit namespace


Of all the Add-ins, excluding yours, which do you see as being the five most ingenious?

I think I would have to put all of Peli’s addins at the top of that list: Graph, CodeMetrics, Review, Pex and ReflectionEmitLanguage.

How would you see an Add-in manager modeled after Firefox encouraging software developers to add new functionality?

I like the way FireFox gives you the ability to easily connect to their addin site and locate new addins. I think for Reflector it would allow users to find updated addins faster and give a central location to search for additional addins, whether on codeplex or not. In general, I figure the more visible the addins are to the end user the more likely that end user will use them and later on decide to write one themselves … though that’s just my theory.

Should Reflector have a conventional installer (with maybe the option to install it into Visual Studio) , or is it better the way it is?

No, I don’t see a lot of value added with an installer – actually it would probably cause more problems than it would solve.

Is Reflector now complete, in the sense that all necessary extensions can be made via the Addin architecture?

No, there are several areas that aren’t available to extend or at least I haven’t found a way to extend yet. The biggest area seems to be the Analyzer.

What sort of extensions could be built if the Analyser had a defined, extendible, architecture?

Hmm good question, because if there really was one that I could think of, it could be built on the existing addin architecture though it would require more work.

You are still very interested in the whole subject of NET disassemblers. Is there still a place for ILASM and ILDASM for the average .NET Developer, or can .NET Reflector do it all?

I would say for the ‘average’ developer these days, Reflector can do it all. These days it seems there is only a small percentage of developers that have ever used ildasm and even a smaller percentage that have used ilasm.

The Debris add-in for Reflector is fascinating because it will allow you to browse a lot of the metadata that you can’t get at with .NET Reflector. What do you see as being its main use?

Debris is aimed at a pretty small audience (seems to be a common theme with most of my addins) so I doubt there will be too many people who will use it. It is really geared towards the ILDasm user who also uses Reflector to view all parts of an assembly .

Is Obfuscation a necessary evil for ISVs to protect their software from corporate giants and hackers or it is just 10 minutes per release build wasted?

Unfortunately I think it is a necessary evil, without it the bar for reverse engineering is way too low … especially for a small ISV who really depends on some time in the market before their competitors catch up. However there are some design tradeoffs that have to be made when the final product is obfuscated, which also has to be taken into account.

Is there anything we can do to get more people involved in writing add-ins?

Maybe borrow something from the Google or Mono camp on how they get people to develop Addins or code for them. Or maybe some sort of a contest, but I’m not sure how that would work.

What, besides Debris, would be a ‘killer Add-in’ for someone to write?

A managed assembly (and file) diff utility that is as usable and useful as Scooter Software’s Beyond Compare – that would be sweet!