AutoCAD, .Net and Cloud technologies

Introduction

It has been quite a while since I last updated this blog and in between a lot has changed personally, professionally and in technology. For instance: German is now the language I speak the most and it has taken its toll on my English, I apologise for that in advance.

Another thing that has changed is my preference of technology when it comes to AutoCAD automation: back when I wrote this post it was Lisp, nowadays I use mostly .Net plugins.

The downside [of Lisp, back in 2013 my go-to AutoCAD automation tech] is that it’s quite a mess to have a GUI for the scripts or routines you develop. I mean, sure, it can be done (there’s DCL after all) but it’s not as flexible or easy as one would hope. Luckily, for most use cases a simple custom toolbar and text input will make users happy.

Turns out, all those issues with GUI development along with some caveats with batch scripting (on hundreds and thousands of DWG files) made Lisp more of a burden than a blessing.

Also, AcCoreConsole happened and Autodesk has been investing in cloud technologies heavily, so AutocadIO and View and Data APIs will be coming strong.

Table of Contents

Why .Net?

Performance and flexibility

Autodesk invested very heavily in creating a powerful, flexible, yet simple .Net API for AutoCAD. It allows developers to do nearly everything that is possible with ObjectARX (the low level C++ API) with a higher level language like C#, F# or VB.Net.

Better tools and support

If you want to write Lisp for Autocad, you will most likely use Notepad++ or the Visual Lisp IDE, which has probably not received significant update since before year 2000; it looks like it’s basically supported for backwards compatibility and to avoid annoying the remaining Lispers amongst us.

With .Net, you can use Visual Studio and its debugging features which are, in my opinion, far better.

It is also easier to structure, maintain and reuse code thanks to shared class libraries.

Purpose oriented routines

Most of my Lisp routines were very generic and defined a couple AutoCAD commands with the most common options. These routines could be quickly extended to do exactly what the user wanted with Lisp one-liners; my experience so far has been that end-users never do that and they end up forgetting commands they don’t use that often.

The reason for that is that most end-users have no experience with simple programming, left alone with Lisp; you can’t really blame them.

Which is why I now focus on providing users with a GUI application that allows them to perform a specific task and adjust the parameters for that in the process. This is much easier in .Net, specially when using WPF for the GUIs.

That being said, I still provide commands that allow programmatic usage of the routines; that means I sometimes use Lisp as some kind of meta-scripting to further automate .Net routines.

Packaging, distribution and deployment

Common issues with Lisp scripts were:

• Users found routine installation too complicated.
• It was difficult to provide users with updates.
• As long as users were in our office, everything worked fine because of custom AutoCAD workspaces; remote or in-client-premises workers were sometimes not as lucky.

Some of these issues were addressed by Autodesk with the introduction of the Autoloader (see the white paper), but others (e.g. updates) persist and are quite difficult do solve with Lisp but not so in .Net.

AcCoreConsole and the Cloud

Back in 2013, Autodesk had already been separating AutoCAD’s GUI from the logic; one of the reasons for that, was to provide a Mac version of AutoCAD. As a result of that separation, the AcCoreConsole was born.

The AcCoreConsole is a headless, minimalistic version of AutoCAD, that can fully interact with a DWG database. For regular users, this means nothing; for developers however, this opened up a world of possibilities.

Suddenly, running a Lisp script in a few hundred files was as easy as preparing a small .bat file that called the AcCoreConsole with the right arguments and invoked the script. All with the performance gains of not having any GUI and not having to render each opened drawing — these performance gains are huge.

This, along with the rise of Amazon Web Services, gave some very clever people in Autodesk the base idea for AutocadIO and View and Data.

AutocadIO is basically a way of running scripts massively in the cloud and View and Data is a way of accessing or displaying drawings in a browser.

The potential of these APIs both in and outside of the engineering world is enormous and they will surely gain importance in the next couple years.

A very cool example prepared by Kean Walmsley is Jigsawify; information on some design decisions and technical details can be found on his blog.

Closing

This post serves as a bit of an update and introduction for the work I’ve been doing in the past few months, stay tuned.