Configuring Reflector in Visual Studio 2008
Red Gate's Reflector (Formerly by Lutz Roeder) is one of those tools that you can technically live without but the question then becomes: why? It is free and makes SharePoint development that much easier. And to be honest, those of us doing serious development in SharePoint can use a few breaks in this area.
The main thing that it gives SharePoint developers is the full name of your compiled dll's (including the PublicKeyToken) in the exact format that you have to use all over SharePoint whenever you reference anything in that library.
The only problem is that Reflector doesn't know where to find your handy DLL, so you have to open Reflector and do File-Open and browse to your newly compiled library. Except, of course, if you configure it as an External Tool (under Tools on the menu) so that Visual Studio tells it where to find your DLL. Easy enough.
For those who like copy-paste, those arguments are :
Compiling your project and running Reflector from the Tools menu now should now show you a whole list of libraries with your custom dll at the bottom. Clicking on your dll name will put information like this at the bottom of the Reflector window where you can then highlight it and copy. Yes, the information is available simply by looking at the GAC but this is much quicker and less prone to typing errors, and is already in the proper format.
The second thing it gives you, which is actually Reflector's main purpose, is immediate and easy disassembly of a library so you can see the code that is actually being executed when you call functions in Microsoft.SharePoint.dll. It also opens you up to a whole new world of frustration, as in: “Why in the world did Microsoft not seal a certain webpart class, but then did seal that webpart's custom toolpart class” Yep. You get to see that stuff too.
Happy reflecting 🙂