Through the Interface: Debugging into AutoCADs .NET API layer using Reflector Part 2

May 2015

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


« Debugging into AutoCAD’s .NET API layer using Reflector – Part 1 | Main | Testing truth »

February 05, 2010

Debugging into AutoCAD’s .NET API layer using Reflector – Part 2

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:

Launching the assembly decompilation

This option launches an analysis of our currently open solution, to understand the assemblies that have been referenced inside it:

Reading assemblies from our solution

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:

Choosing AutoCAD's assemblies to decompile

Selecting OK causes the decompilation process to start on these assemblies:

Decompiling AutoCAD's 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):

Finished decompilation

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):

Details of methods that failed to decompile

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:

Debugging our Line's Extend call

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):

Debugging the subtraction operator between a point and a vectorAnd 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):

Debugging the actual Extend call

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).

blog comments powered by Disqus


10 Random Posts