Why Reflector is critical and a little WCF Ajax exception handling
When I am interviewing Senior .Net developers if they don’t know what Reflector is and what it does I assume they really aren’t that "Senior". I use Reflector in two ways. First and most important to disassemble code, especially Microsoft code, so I can avoid reading often inadequate documentation on how an API can be used. Second is to learn by seeing how other developers have coded different patterns based upon a similar piece of code or architecture I am working on.
The best memory I have of how Reflector helped me is when .Net WCF 3.5 was released to support Ajax and JSON. Knowing a good amount about how WCF worked I wanted to handle Fault Exceptions by providing my own JSON messages back to the client instead of the default JSON Exception message. I read documentation and looked at some Blogs to no avail. I then took the direct approach and went straight to the source, literally, and to my shock and disappointment found that Microsoft had "Sealed" their new WebScriptEnablingBehavior class! While I pondered the merits of starting from the base WebHttpBehavior and writing all that code that the "SEALED!" class provided I finally accepted that wasn’t the best approach. But because, thanks to Reflector, I could see the exact code they used to provide their exception message I could adapt my strategy to make use of what they had done.