There are lots of reasons to want to use the newly-released Visual Studio 2013 to develop and debug .NET modules for AutoCAD. One of the main ones is the long-awaited addition of Edit & Continue support for 64-bit applications. Unfortunately in this post we’ll see why, despite the wait, E&C isn’t going to work when debugging 64-bit .NET modules inside AutoCAD.
The primary issue when running AutoCAD from the VS2013 debugger manifests itself in issues with font loading. If you launch AutoCAD from VS2013 to debug a 64-bit class library – even without actually loading the module – then AutoCAD will crash when you run commands such as STYLE (which attempts to display font information in the dialog). This is true for all versions of AutoCAD I tested with; going back to AutoCAD 2013, but presumably it’s also true for versions prior to that.
Thanks to Samir Bittar for bringing this issue to my attention. It seems the issue has also been discussed at some length on the discussion forums. Within the AutoCAD Engineering team, the issue has been researched very thoroughly by Arthur Ding, an engineer based in our Shanghai office. Arthur discovered how VS2013 works differently to VS2012 when debugging .NET modules and invalidates a core assumption made inside AutoCAD.
When VS2013 launches AutoCAD – at least via the debugging code-path that enables Edit & Continue – an additional thread gets created and is used to load the basic modules – such as acdb*.dll – into the process before exiting. With VS2012 this is not the case: it’s AutoCAD’s main thread that loads the basic modules, just as it would when run outside of a debugger. Our AcDb module naturally expects to have been loaded by AutoCAD’s main thread and so caches the loading thread’s ID for later use.
The main place the issue is currently encountered is when accessing certain fonts: the loading fails for these fonts as the load attempt is made from a thread that AcDb doesn’t recognise as being the main one (and for safety’s sake this is disallowed by AcDb – it isn’t thread-safe and so prevents access to database operations from an arbitrary thread). When the font is then accessed – for instance in the STYLE dialog or the MTEXT editor – this either leads to (at best) an error or (at worst) a crash.
The good news is that there are two simple approaches that can be used to avoid this problem using VS2013, either of which should stop AutoCAD from crashing (due to this particular problem, anyway).
- Turn on “Use Managed Compatibility Mode” via Tools –> Options –> Debugging.
- Turn on “Enable native code debugging” from Project –> Properties –> Debug.
The latter one comes with a performance penalty, as it obviously has more work to do paying attention to the unmanaged code in AutoCAD and the underlying OS (of which there is a fair bit).
The bad news is that both of these two options disable Edit & Continue for 64-bit applications. So while it’s possible to make use of VS2013 to debug 64-bit .NET modules using one of the above approaches, you won’t be able to make use of one of VS2013’s most eagerly-awaited new features while doing so.
[It seems there are also issues when debugging Revit with VS2013. See this post on Jeremy’s blog for more information on that.]
