By Chris Massey and Ben Holtzman, June 25th, 2012
A little while ago, I got an email from Ben, who'd been using .NET Reflector. We'd asked how his trial was going, and he told us about how Reflector let him drill down to a problem in 3rd party code in no time at all. It's great to learn more about how the tool is being used, so we invited Ben to give us a little more detail:
We're developing the GUI for a robotics motion control system, to be used by a component creator that supplies a large chip manufacturer with components. The GUI lets the operator create very precise patterns (in the microns) to dispense goop at high speeds. The GUI design calls for the layout to be customizable in terms of what controls are present, their layout, what size they are, and what colors are used to render the controls. To help accomplish this we were using a mixture of our own components and 3rd party Telerik controls for WPF.
Unfortunately, we were having trouble with a control called RadPane, which is a container control. One section of this 3rd party control was erring out under certain conditions, and would display a very unhelpful “source code unavailable” message upon crashing. I used .NET Reflector to easily decompile the involved dll and run the debugger through the now present source code.
The whole process was mostly automatic, actually. I downloaded the .NET Reflector trial and installed the Visual Studio component. Using the new VS menu option for .NET Reflector, I opened up the Telerik dll that was returning the unhelpful message and then ran the GUI to reproduce the error. The VS2010 debugger highlighted the newly-available source code, and let me know that the issue was with passing in an uninitialized variable. So now I knew what was causing the crash.
I rewound the stack frame to our own call to the dll, and found exactly where the call to the Telerik control was being made and why the variable was uninitialized. As it turned out, we were failing to find an existing control before trying to add it to the pane's content for one of our newly created user controls. Trying to set layout and color properties for a non-existent control broke the application inside the 3rd party code.
.NET Reflector saved me hours worth of work in trying to guess where the issue was occurring. Without it, I would have had to place breakpoints before and after where I thought the issue might be happening and work through what breakpoints tripped, and what the application conditions were while the program progressed from our code to 3rd party code and back again.
Even then, since the 3rd party code didn't have any source code I wouldn't be able to tell where the issues started to become visible. So the whole process would have involved a great deal of guesswork. With .net reflector the whole processes took about ten minutes (which included playing around with the new tool a bit), and let me find out exactly where and what the problem was.
Ben Holtzman
We're really grateful to Ben for sharing this with us, and as a small token of thanks we've sent him a free copy of .NET Reflector VSPro (seeing as the trial saved him so much time already).
