Over the years of running HowToAutoCAD.com I have found that hundreds, if not thousands of you are very keen to get into writing your own tools for AutoCAD®. However, you can create tools for AutoCAD® using VB.NET in many ways, and I often see people unsure about the difference between COM automation and using a managed .NET solution.
Without this fundamental understanding you’re going to get confused at some point why something isn’t working. So that’s the point of this post – to explain the differences, and why it’s generally better to use managed code.
What is COM ?
If you’re creating a program, you can quite easily declare a variable and use it in your code. However, if you have two programs that run separately, you don’t have access to one program from the other. If you wanted to access the value of the variable created in one program from the other, you can’t – you’re stuck.
This is why Microsoft invented COM, which stands for Component Object Model. It sets out a standard for how programs can interact with each other. What this essentially means is that we can write code in one program (say Excel for example) to automate another program (say AutoCAD).
For example, we could write this VBA code in Excel:
Set ACAD = GetObject(, “AutoCAD.Application”)
ACAD.ActiveDocument.Utility.Prompt “Hello from Excel!”
This would send an instruction to AutoCAD®, through the COM interface, telling AutoCAD® to prompt the user with the text “Hello from Excel!”.
This is fundamentally a great idea for solving the problem of communicating between processes, and it has been a very useful way to automate programs over the years. However, COM does have its limitations.
What are the limitations of COM ?
In order to get COM working, Autodesk have to create and maintain a COM interface for AutoCAD®, so that other programs can use this COM interface. This also means that Autodesk have to explicitly create a COM interface for each feature, which also means that new functionality will not automatically work with COM. A new COM interface would have to be created.
Having to write an explicit interface for every bit of functionality makes it impractical for Autodesk to support everything. And, unless Autodesk have written a COM interface for what you want to achieve, you’re stuck.
This is essentially the problem with COM, and communicating between two programs (or processes). You’re limited to communicating through mechanisms that are supported by each of the programs.
What does the NETLOAD command actually do ?
You may have used the NETLOAD command before – this command takes a DLL file, and loads it into AutoCAD®. This means that the functionality that the DLL contains has actually been loaded into the AutoCAD® process, which eliminates the requirement to communicate between two programs (or processes).
This means that you no longer need to use a technology like COM, because you have direct access to the internals of AutoCAD® already. This gives us much more power to do what we want, and it is much easier to manipulate AutoCAD® from the inside than from the outside.
This makes using a loaded DLL very much the preferred option.
But what does “managed” code mean ?
Throughout the course of writing an application the size of AutoCAD®, you would need to create many internal classes and subroutines for handling the behaviour of various aspects of the application. Being a DLL inside the AutoCAD® process gives us some access to these internals, which allows us to integrate far more closely with the AutoCAD® application, and potentially achieve much more, in a much more efficient way.
But in order to interact with the internals of AutoCAD®, as programmers we need to know what these internals are. Furthermore, we need to write our code in such a way that it uses the internals of AutoCAD® correctly.
In effect, we have to manage our code, so that we are using the same application programming interfaces (APIs) that are used by the application itself.
So for example, if AutoCAD® has an internal function called “DrawLine()”, then we should also use the function “DrawLine()” in our code as well (assuming of course we want to draw a line ;-)).
How do we know what APIs there are ?
The first thing to do is create a reference in your .NET project to the AutoCAD® Type Libraries. To do this, you’ll want to right click on your project in VB.NET, and select the option to add a reference. This will pop up the form below:
For access to the managed libraries in AutoCAD®, you’ll want to select “acdbmgd.dll”, “acmgd.dll” and “accoremgd.dll”. This will add the relevant type libraries to your VB.NET project, and you can then use these in your code.
What next ?
Well now you hopefully understand the difference between COM and managed .NET code. The next step is to create your first .NET project using these libraries. You’ll need to create your VB.NET project as a class library, which should cause it to compile to a DLL. Also be careful to select the appropriate VB.NET framework to use when compiling your .NET project to a DLL. Ideally you will want to target the .NET framework that your version of AutoCAD® uses. You can do this by right clicking on your project, and selecting properties, and then in the Compile options. Then build your project from the debug menu, and then use NETLOAD to load your DLL, and if all went to plan you have successfully created a managed VB.NET project for AutoCAD.
That’s my piece for today – I hope this article was helpful.
P.S. Don’t forget to subscribe if you found this article helpful – more tips and tutorials to come