VS2010 Debugger and Autodesk Civil 3D 2012 breakpoint and no-source issues

I know, I should blog more. But unfortunately I just don’t have enough time to keep up so I stick to only blogging about what I think has value or is worthwhile or fun to mention. Whether this post is funny, worthwhile, or valuable I’ll leave up to the reader to decide.

If you are having trouble debugging your addons/plugins for Autodesk Civil 3D release 2012 you are certainly going to want to read this. The information presented also appears to be applicable to other products such as Autodesk Inventor 2012 and AutoCAD MEP. Probably even all AutoCAD 2012 based products.

You probably found this post while searching for things relating to debugging your AutoCAD Civil 3D 2012 addons and running into a problem where the Visual Studio 2010 debugger fails to hit your breakpoints and does not show you the source of your application that you are debugging. If that’s the case, you are not alone, and you are looking for some detailed information about this problem.

It is starting to become clear that others are inquiring about this very same problem at the Autodesk forums for Autodesk Inventor as you can read about here (screenshot). Liam Smith believes this might be an issue with the location of PDB’s. Which is a logical enough assumption but very likely not what is really going on.

Allen Holman, on the other hand, thought this could be a VS2010 problem and sought help on the Microsoft MSDN forums. Instead of finding answers to the problem he’s trying to identify and solve, however, Allen gets publically accused by an Autodesk employee (Chris P. Johnson) of trying to break the licensing of the product and is reminded of the unethical nature of such activities as you can read here (screenshot). Chris adds that he confirmed that Allen is not an Autodesk employee, which is within his capabilities since Chris does work there.

It is so disappointing to see an Autodesk employee communicate in such a manner but it does make me wonder if I should conclude that developers who run into this particular debugger problem and attempt to seek a solution publically are to be accused of acts of breaking the licensing. I don’t know if Chris is fully aware that the accusation, depending on the country of origin of the original poster, constitutes a crime. Are all developers creating plugins for host products and wish to use their debugger and breakpoints suddenly potential software pirates?! To to best of my knowledge Chris doesn’t even work on AutoCAD based products but in a different product group.

Please Chris, if you don’t have something of value to bring to a problem forward it to someone within the organization that could help and don’t start accusing developers, publically. Think about what you’re writing in public and how this reflects on your employer.

Now, for everyone running into a “no source” and failure to hit breakpoints while debugging, your solution is very simple:

DO NOT CREATE MICROSOFT .NET 4.0 ADDONS for Autodesk Civil 3D 2012 if you wish to use the Visual Studio 2010 debugger. OR use the FIBERWORLD and NEXTFIBERWORLD ‘workaround’.

It’s that simple.

If you want to create .NET 3.5 addons and be able to use your debugger you will have to do two things. First, make sure your addon is targeting the .NET Framework version 3.5 (or 2.0). Second, change the acad.exe.config file so it reads:

<supportedRuntime version="v2.0.50727" />

instead of

<supportedRuntime version="v4.0"/>

The reason you need to do this is explained over at this blog (screenshot) and also this blog (screenshot). Unfortunately both of those detailed descriptions fails to mention the situation specific to .NET 4.0 using VS2010. It is as if this particular situation, which is the most logical situation if you want to develop .NET 4.0 addons for a .NET 4.0 host application, is obfuscated by the many technical explanations regarding this issue but is not actually addressed in any way.

All my tests, and trust me, those have been extensive and went as far as building clean VM’s to repro the problem in detail, show that while Autodesk’s 2012 release says it’s .NET 4.0, it fails to mention that it comes with a few quirks that prevent you from actually using .NET 4.0 features if you also wish to use your debugger. I consider a debugger to be the bread and butter of every developer so unless you wish to give up debugging, stick with .NET 3.5 and make the change in the config file or make use of the following, much better, and much more useful FIBERWORLD workaround for the problem.

Another thing to pay attention to is that this particular problem debugging .NET 4.0 addons for AutoCAD 2012 based products is that they are particularly prevalent when you are setting breakpoints inside the code of a Windows Form. There is some awful context switch going on. For example, you can still debug into the .ctor of a Form and code called by the .ctor but not any other code in the Form. Likewise, you can also debug into and hit breakpoints on code that is unrelated to any Windows Form. So even when you think you’re not hitting this problem, try it when using some Windows Forms. I have had mixed success using modeless vs. modal forms but in the end it doesn’t take much for the problem to rear its ugly head. Additional information about this particular fiber issue can be found on this page (and its original source in Chinese).

In case the Chinese is too hard for you to follow (it is for me too). There’s a system variable in AutoCAD called FIBERWORLD (read only and set to 1). If you start C3D from your debugger you can check this variable as being 1. Then just set NEXTFIBERWORLD to 0 (zero). Close all documents. Open your new document and start debugging. You will find FIBERWORLD be set to 0 (zero), also solving the problem.

Isn’t it surprising how this information comes from a far-away source and not from more official sources like at this blog (screenshot) and also this blog (screenshot)? The latter even gives an answer in the comments that they (Autodesk) have no idea about any of this.

So there you have it, the solution to your 2012 + VS2010 breakpoint/debugger/no source problems. And all without being accused of being a software pirate trying to circumvent the product’s licensing.

On a final note, though, expect a major performance hit when debugging .NET 4.0 using an AutoCAD 2012 based product. I am seeing a huge difference in performance when running and debugging with Civil 3D 2012 and a complex drawing using .NET 4.0. The 3.5 version and its associated workaround for the debugger issue does not lag and creep along as slow.