Introduction to managed VB.NET code for AutoCAD®
Hello everyone.
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.
Will
P.S. Don't forget to subscribe if you found this article helpful - more tips and tutorials to come :-)
Comments
Vahid
2013-04-28 09:18:46
Concise and to the point. It is amazing that I always find stuff here that I want to continue writing my program. It is like you are reading my mind! Thanks
Will
2013-04-28 09:41:17
No problem Vahid, glad I could help ;-)
Chris
2013-04-30 20:16:43
NOW this is the stuff i subscribed for!!! Excellent... Love the way you start simple and build on. (as you should). Keep Building! I have a VB program i wrote a few years ago, and have been wondering if i have to re-write it or somehow port it over. The more i understand the better idea i will have on which way i will have to go. If you would like to see it (as an example of Poor code!) let me know. Would love to see you hack it for correctness (or show how hard i made it when something couldve been done simpler)
Keep these posts coming.
Will
2013-05-01 12:51:03
Thanks for your kind words. I'd certainly be interested to see your work - feel free to forward on !
Chris
2015-06-22 20:54:52
so, how do I go about send you the files?
Mark Ogles
2013-06-01 13:34:08
Will, I have found a lot of useful information on your site. Thanks. The one thing I have not found, and it seems to be missing on the web is the way in which you can use your own forms in managed code. This is a big deal in my opinion. Of course someone may hold this information back so you buy the book, but I have done that and the method didn't work. I am using VSVB 2012 and Acad 2014. There may have been a difference between the book and the tools I have to use. Can you put this on your list of articles?
Will
2013-06-09 10:12:32
Good point Mark - I'll get on it asap.
Avinash
2014-08-11 11:49:38
Hello,
Do you have a sample project which small one created in VS 2012 for AutoCAD® 2015. I have already in VS 2010 with AutoCAD® 2014 it's working fine. I have upgraded to AutoCAD® 2015 and VS 2012. It is not working.
Please help me.
Avinash
Bytekodes
2014-09-30 10:06:29
Thanks once again Will, This piece is a spot on for me, especially with my passion for VB.Net. Thanks!
But, how can I know the type library to reference if I need to automate AutoCAD® processes in Visual studio?? I m comfortable with VS2008 for now!
Best Regards.