Lutz Roeder .NET Reflector is a tool that should be in the toolkit of every .NET developer. It is, as its website described it, a "class browser, explorer, analyzer and documentation viewer for .NET". It allows you to crack open any (non-obfusicated) .NET assembly to see the types inside. It can also analyse the type hierarchy and the use of types by other types both in the same assembly and in other assemblies. The decompiler can decompile types into a variety of languages, including IL, C#, VB.NET and Delphi.

There are two primary questions I've received when telling people about .NET Reflector. The first is a legitimate concern about the intellectual property implications of reverse engineering other people's code. The second question concerns the utility of the tool. This query comes in two forms, legitimate inquiries as to the utility of the tool, and a close minded "don't make me learn anything new" from developers happy to continue being mediocre. I'll address the first form, if your attitude matches the second then please change career.

Intellectual property concerns are obviously very important. Cracking open a commercial assembly and copying its implementation is obviously illegal and I don't in any way condone it. Use of .NET Reflector to facilitate interoperability or the legitimate use of software is a grey area. I'm not a lawyer, so I don't know the legalities here, but it's probably best not to risk it. For things such as the .NET Framework downloading the source code release Microsoft recently made available would be a better option and would provide clear licensing terms.

If you can't use .NET Reflector on commercial assemblies for legal reasons then what use is it? .NET Reflector still provides significant value when used with assemblies that you can legally examine, that is your own and open source code.

Once you've determined what you can legally examine, the question remains why you'd want to. After all, you already have the source code for your own assemblies, as well as those from open source products. It turns out there are a number of scenarios where .NET Reflector is a better tool for looking at the code (technically, a decompiled version of the code) than looking at the actual source files.

.NET Reflector provides a number of analysis options that can navigate between assemblies. There are many cases where this is more effective and significantly faster than looking at the source code. This is especially true when the code is split across multiple solutions. .NET Reflector doesn't care about the orgnisation of the source that built the assemblies it examines. You can therefore load up assemblies built from many solutions and easily see the dependencies between them. This is invaluable on large projects or when you are using third party tools (NHibernate for example).

It is also somewhat naive to assume you will always have the source code for an assembly. Even if you have a solid source control system you may not have a way to track exactly what version went into building any particular assembly. .NET Reflector provides a way to examine the content. There have been occasions where I have been called on to help a team that didn't know precisely the content of the assemblies they had in production due to a failure of their process. I was able to determine the differences between the production version and other versions (test and trunk in source control) by using .NET Reflector with a plugin that extends it to decompile the entire assembly and write the result to the file system. From this I could run a diff tool and see the places where the versions diverged. From there it was a simple matter to sync the desirable changes into the source control trunk, ensuring no behaviour was lost.

More recently I've used .NET Reflector to learn IL. While building a dynamic method to invoke arbitrary methods on arbitrary classes I used .NET Reflector to decompile code that did what I wanted to IL. This, coupled with MSDN documentation, was sufficient to allow me to write my own IL.

.NET Reflector is not an everyday tool in the same way as a compiler or IDE. It is however an invaluable addition to your toolkit for the non-standard cases where other tools fall down.