Disclaimer: RedGate is a sponsor of devlicio.us and offered a copy of the product and a ThinkGeek gift certificate as an incentive to review their product. This review is the work of the author and was not approved by anyone other than the author. There, now you know the kind of taint this review has. Please keep reading anyhow. OK? Good!
.NET Reflector is part of any respectable .NET developer’s tool belt. When you want to figure out how something works, why your code breaks when interacting with some library, you view the assembly through .NET Reflector’s lens. The latest version, 6.1.0.11, will display the IL in an assembly as IL, Managed C++, VB.NET, C#, Delphi, or Oxygene. The latest version has been updated to support .NET 4 and allows you to jump into .NET Reflector from Visual Studio. I was disappointed to see that the “Open in .NET Reflector” menu option is only available from the Object Explorer. I would have expected to see this option by right-clicking on the assembly from the References list in the Solution Explorer, but no. Given that other tools (TestDriven.NET in particular) do add this functionality (they actually add “Open in .NET Reflector” from the Solution Explorer!) RedGate needs to address this usability issue.
Otherwise, the free version of .NET Reflector hasn’t changed. It is still a great tool.
So, what about this new, Pro version? First, it costs $195 US. What do you get for that price? You get the ability to generate source code and PDBs so that you can step through the assemblies you use in the languages you know. If you are debugging Microsoft provided assemblies, you can already step through assemblies using the actual source (typically C#) through the Enable .NET Framework Source Stepping option from the Options dialog (in VS 2008/2010, access this dialog from Tools->Options menu.)
In the past, Microsoft wasn’t always good about keeping their symbol servers and source code servers up to date. Not every group put their code into the repository right away, so service packs and other patches might cause you to lose the ability to step through code. If you use components from other vendors, this option does you no good at all. RedGate is betting that a number of you want to be able to step through all .NET assemblies in VB.NET or C#. At a high level, RedGate generates the source code for an entire assembly and dumps it onto disk. It also writes out a PDB that tells Visual Studio how to map the assembly code to the generated code.
To long time users of .NET Reflector, the code generation piece may sound like old hat. It is. Back in May of 2004, Denis Bauer released a .NET Reflector plug-in that dumps the assembly information as code files (the plug-in was last updated for .NET Reflector v5). If you want a full project file for the dumped files, you used Jason Bock‘s FileGenerator plugin. Unfortunately, neither of these allow you to step through code, and that’s what many of us need. .NET Reflector Pro adds that functionality.
The overall experience is seamless. Upon running .NET Reflector, the .NET Reflector top level menu is added to Visual Studio 2008/2010. From here, you can either decompile an assembly in your project, Explore Decompiled Assemblies, or Debug an Executable.
Explore Decompiled Assemblies just pops open the Object Explorer in Visual Studio. I would have expected the list to be reduced to the list of assemblies I had already decompiled, but that isn’t what happened. Debug an Executable is a bit confusing too-it just fires up the executable and attached the debugger. If you have decompiled the assemblies of interest already, you can step through that code. Otherwise, this feature seems to be a bit of a waste. When PDB information does not exist, I would have expected the UI to say something like “.NET Reflector has not created debugging information for the selected executable. Would you like to generate source code and PDBs now?” I should then be able to select the assemblies I want to debug using this new functionality.
All that said, the tool does redeem itself. When selecting .NET Reflector->Choose Assemblies to Debug, the tool gets things right. This is the only feature in the Pro version that seems to have been completely thought out. At this stage, you are presented with the following dialog:
You can generate the source in C# v2.0/3.0 or Visual Basic 8.0/9.0. You then select the assemblies you would like to be able to step through and press OK. A little while later (time completely dependent on the size of the assembly), you are ready to do source level debugging. In the I tested out, this worked as advertised. I was able to step into System.dll, System.Web.dll, and other assemblies I regularly use. So, for .NET 4.0, clearly a win. F11 works fine, you can set breakpoints etc. For .NET 4.0 developers, this will be very helpful debugging those nasty issues where you need to figure out why your code is causing .NET and other libraries to die.
So, how about Silverlight? I had .NET Reflector generate the source/debug information for System.Windows. Then, I set a breakpoint in the constructor for my Silverlight MainPage.xaml.cs. I was able to step out to MS.Internal.CoreInvokeHandler.InvokeEventHandler.
I tried doing the same thing with the just released Windows Phone SDK. In this case, I was unable to get the application to rebuild correctly and work. After instructing .NET Reflector to generate the information for System.Windows for a Windows Phone Application, I saw this dialog:
After generating the assemblies, Reflector pointed the references in the solution to the new assemblies. Upon debugging, I saw this message (followed by several more for the other updated assemblies):
—————————
.NET Reflector
—————————
The loaded assembly "System.Windows" is not the one .NET Reflector expected.
Expected version: "c:tempregenSystem.Windows.dll"
Loaded version: "System.Windows.dll"
If the correct assembly is not loaded, debugging may not work.
—————————
OK
—————————
If you are doing any Windows Phone development, the tool does not work for you. I imagine that this shortcoming will be addressed in the coming months-the SDK was only recently released.
Other things I noticed
The source code gets dropped into an AppData folder. For example, the code for MS.Internal.CoreInvokeHandler is at:
C:UsersScott SeelyAppDataLocalRed Gate.NET Reflector 6CacheV4x86CSV35c46bf0b4-91fb-4aa9-8732-63fe4e8d7afcMSInternalCoreInvokeHandler.cs
Looking in the v35 directory, we see that a PDB is dumped out:
c:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0System.Windows.dll
For an assembly in the GAC, System.Windows.Forms, the assemblyLoc file points to it’s GAC location:
C:WindowsMicrosoft.NetassemblyGAC_MSILSystem.Windows.Formsv4.0_4.0.0.0__b77a5c561934e089System.Windows.Forms.dll
which appears to say that the symbols are generated from that particular reference assembly. The GUID named folder contains source code.
Summary
Having access to source and single stepping helps me troubleshoot problems faster because I can see why the underlying code doesn’t like what I’m doing when consuming the class libraries. Like most developer tools, this one has its value in the time savings you will get by getting you to the why of a bug in less time. I like the tool because it doesn’t change how I do my day job. It gives me access to more code so I can poke down the debug path even further without pulling out Reflector to grok why my code isn’t behaving as expected. And, I can easily make stepping into other people’s code part of my daily workflow.
Overall, I like the enhancements and am looking forward to using .NET Reflector Pro.
Karmic Code Monkey 