Getting the most out of Reflector

Reflector has been out for years now. It's ubiquitous and a staple for many .NET developers. But, I think it's taken for granted because of it's ubiquity. I'll outline how I use Reflector and show how I wouldn't be able to develop .NET software as well without it.

In the days of .NET 1.x, what the .NET languages produced mapped, more-or-less, one-to-one with the language constructs of Intermediate Language (IL or MSIL). That is, it was easy to reverse from IL back to C#.

View Code From the Point Of View of a Previous Language Version

Viewing the IL generated by a compiler is often useful in understanding what the compiler is doing, and thus the consequences. But, you can also disassemble code into a prior version of the language. For example, if you write the following C# code

 void fileSystemWatcher_Created(object sender, FileSystemEventArgs e)


 {


 if(this.InvokeRequired)


 {


 this.BeginInvoke((MethodInvoker)delegate() { fileSystemWatcher_Created(sender, e); });


 }


 UpdateFileList();


 }

Reflector will show the same code (the only difference will be formatting). But, you can tell Reflector what version of the language you want code to be shown in. This can be done in ViewOptions:

You can change the Optimization to a prior version of .NET, for example .NET 1.0. When this code is viewed it .NET 1.0 Optimization you see this:

This shows clearly what is happening in the behind-the-scenes.

Let's face it, API documentation sometimes isn't as detailed as it needs to be, and lack of Design by Contract (DbC) doesn't help.

Akin to the above point, sometimes the documented examples are academic, and sometimes (although showing syntax perfectly) violate fundamental principles of correctly-written software. And, although it's no guarantee of finding correctly written code, you're likely to find real-world examples of API usage.