Why is Reflector such an essential utility?

Question

Reading the brouhaha surrounding Reflector going paid got me thinking about the product and its uses. Many people seem to consider it an essential tool.

I have to admit, I haven't used Reflector in years. I mean, there's documentation for both the .Net APIs and the third party components I use. In the past, whenever a colleague pulled Reflector out of his tool belt, I got the sense he was headed into the weeds.

Reading all the passion around Reflector is leading me to question if I'm really missing something here. Why do you need something like Reflector so often that you consider it an essential tool? I can see it being needed on very rare occasions, but not enough to be considered an essential tool. Please enlighten me.

Answer 1

Here's a perfect example of the type of question .NET Reflector can answer for you.

Or you can post it on SO and let someone else with Reflector installed answer it for you. ;)

Answer 2

I use reflector on a fairly regular basis (maybe one or twice a week on average) to help with with two different issues.

1. Poorly documented API/Library: My favorite example for this is SharePoint. Most every developer I know of doing SharePoint development uses it to supplement the available documentation. Could we get by without it, for the most part yes; but there have been a number of cases were it would have been rather difficult.

2. Debugging a obscure error: It can also be useful in figuring out why something is throwing an exception. If you can see where the exception occurred you can trace back out the call chain to figure out what the issue is (either incorrectly using a library, bug, etc.).

Answer 3

Reflector is essential when you have some third party assembly you have to use and it's either poorly documented or has bugs in it and you want to know what's going on with its code.

Sure, all you have to do is obfuscate your code and Reflector is useless (or it was last time I checked) but it's saved me a lot of time and frustration in the past.

Also, I've had at least one occasion where I've lost source code (in my pre-version control era) but had the compiled code and Reflector helped me get my code back. Needed a lot of work because comments, variable names, etc. are wrong but it helped.

Also, sometimes you have code in, say, VB.NET and you want to see how it would be done in, say, C# and Reflector can switch between the various languages.

Answer 4

When using Reflection.Emit to generate assemblies at runtime, Reflector becomes an extremely valuable tool for visually verifying the generated code is as you expect.

Answer 5

Reflector helps you discover when the documentation is wrong. I found a bug in the CLR's StringBuilder documentation way back in .NET 1.1. The documentation for the Length property said this:

If the specified length is greater than the current length, the end of the string value of this instance is padded with spaces.

I tried to use the StringBuilder with this in mind, and got bizarre results. I used Reflector, and saw the problem. The documentation for the Length property in .NET 2.0 and forward has the correct information:

If the specified length is greater than the current length, the end of the string value of the current StringBuilder object is padded with the Unicode NULL character (U+0000).

This can make a big difference if, say, you're displaying the resulting text with a MessageBox; the MessageBox cuts off the text at the first null character.

Reflector makes it possible to find out things like this, to see how the CLR really behaves, as opposed to what the documentation says, or to answer questions the documentation just doesn't answer.

Answer 6

Sometimes it is simpler to understand what a library is doing, how it is doing it, and to appropriately use it by looking at its source code.

Other times, I am simply curious and want to peek.

Another common way I use Reflector is to see how the Framework itself implements something.

On occasion, I have a library being used in a really old project and we don't have any source code or documentation. Reflector is quite invaluable in those situations.

I've also used it to hot-patch assemblies. There's been a few cases where I've needed to tweak an internal bit of a library I cannot rebuild and using Reflector to find the appropriate point and then modify the assembly's IL (no, I'm not talking about cracking, but legitimate uses of this functionality).

Answer 7

I would not say that it is essential. But in the rare cases where you really need it, it is highly useful.

Take an example.

Recently I had to create some piece of code that could runtime create the expression tree for the following, but without knowing the name of the dependent property at compile time:

Expression<Func<TMock, TDependency>> expression = (x => x.Dependency);

In order to dynamically set up a mock (using the Moq framework).

mock.Setup(expression).Returns(dependency);

What I did was that I compiled the original expression using concrete types, then using reflector, I found out that I had to write the following code:

var argument = Expression.Parameter(typeof(TMock), "x");
var getPropertyExpression = Expression.Property(argument, propertyInfo.Name);
var lambda = Expression.Lambda<Func<TMock, TDependency>>(getPropertyExpression, argument);            
Expression<Func<TMock, TDependency>> expression = lambda;    

I would have been able to figure this out using trial and error. But reflector made it easy.

Answer 8

Because if you know how to use it, you don't need documentation - and most APIs don't have any meaningful documentation.