In the first post in this series we looked at the basic (and free) capabilities of the upcoming version 6 of .NET Reflector. Today we’ll look at the “Pro” capabilities, which integrate decompilation with debugging of 3rd party assemblies.
To get started, we should see a new “.NET Reflector” toolbar inside our Visual Studio installation. On it, we should see a “Choose Assemblies to Debug…” option:
This option launches an analysis of our currently open solution, to understand the assemblies that have been referenced inside it:
One very important thing to note: for Reflector to work, you must have assembly references to the versions of acmgd.dll and acdbmgd.dll found in AutoCAD’s Program Files folder. If you’re using the “liposuctioned” assemblies provided in the ObjectARX SDK (which are absolutely the right ones to use under normal circumstances) then you’ll get an error such as “Object reference not set to an instance of an object”, at least with the Beta version of this tool I tried.
To get started with the decompilation, we select AcMgd and AcDbMgd from the assembly list:
Selecting OK causes the decompilation process to start on these assemblies:
Once complete, we see a notice describing the results. For the AutoCAD 2010 assemblies there were 28 methods that failed to decompile (and 19,390 which decompiled successfully):
Looking at the details, we can see that the majority of the non-decompiled (for want of a better word :-) methods belong to the ObjectId class (whether due to an optimization we make on that class or a bug in Reflector’s decompilation algorithm):
The decompilation has added about 33 Mb of data to Reflector’s “Debug Store” (which appears to be under C:\Users\username\AppData\Local\Red Gate\.NET Reflector 6\Cache, at least on my system).
Now we can go ahead and debug as normal and see the results. Let’s start by adding a breakpoint to our Extend method. Once it hits, we can step into the code:
Firstly we’ll see some code that shows us retrieving the StartPoint property of a Line (which I haven’t shown here), and then we get to debug the use of the subtraction operator between a point and a vector (which we can see subtracts the coordinate values of the vector from those of the point before returning the point):
And next we get to see that the Extend call is simple a call through to an unmanaged ObjectARX interface (which happens to be AcDbCurve::extend(), not that this is in any way obvious from the decompiled code):
Fun stuff! I can see this being of great interest to people who like to get under the hood of software components, although clearly a lot will depend on the cost at which the tool is made available (and about this I have no clue).
