4

I'm developing an AutoCAD add-in, which uses a .NET 4.6 assembly. I am finding the development process very frustrating; the API is very large and the documentation beyond getting started is all over the place and very hard to find. The only way to get anything done seems to be just prototyping functions in Visual Studio and seeing if it works. It then takes several minutes to load up AutoCAD and attach a debugger, which wrecks my prototyping workflow.

It would be very handy if I could have something like Linqpad to prototype my applications so I can find the data that I'm looking for. I'm not married to the idea of using Linqpad; however, if there's another technique I'm missing I'd love to hear about it.

I'm not sure if this is something I might achieve with the pro version but as there is no trial I can't find out.

Nik
  • 1,780
  • 1
  • 14
  • 23
Steve Rukuts
  • 9,167
  • 3
  • 50
  • 72
  • What is your process for testing/debugging code? Several minutes to load up autocad and attach a debugger doesn't sound right (way too long). Hopefully this is something I can help with. – Nik Oct 23 '17 at 15:38
  • Compiling is almost instant but actually loading AutoCAD, opening the target model, attaching a debugger and loading the assembly are all separate steps. It seems that if you start AutoCAD with a debugger from the start it crashes (anti-piracy measure perhaps?). I looked into live-reloading the plugin but it'd be in another app domain which would mean I'd have to figure out how to invoke cross-appdomain. – Steve Rukuts Oct 23 '17 at 16:51
  • What I do is: in Visual Studio in the .NET dll that has the Add-in code, go to Properties -> Debug -> Start Action, select "Start external program:", and paste `C:\Program Files\Autodesk\AutoCAD 2015\acad.exe` (this will be different depending on your AutoCAD version). Then below, enter `/nologo` into the "Command line arguments:" field (this will considerably speed up AutoCad loading). Have you tried this? Is this where you are getting the crash? – Nik Oct 23 '17 at 17:05
  • And of course, pressing F5, will start AutoCAD and load your assembly into the debugger where you can step through lines of code. This should not take longer than 5 to 10 seconds, depending on your machine. – Nik Oct 23 '17 at 17:19
  • Yes, adding `/nologo` did the trick, that sped things up quite a lot in fact. Thanks a lot @Nik – Steve Rukuts Oct 23 '17 at 17:24
  • OK, great! No crashes or unhandled exceptions when you do this (I had this problem initially)? BTW, you can also add `/nologo` to the AutoCAD desktop shortcut in the "Target" field for your users. It will also help them load AutoCad much faster. If this solves your issues, I'd like to post this as an answer to help anyone with the same issues in the future. Let me know. – Nik Oct 23 '17 at 17:29
  • Yes please do post it as an answer. Do you happen to know how to issue the NETLOAD command via CLI also? I can't find any documentation on that; is there some sort of script? – Steve Rukuts Oct 23 '17 at 18:41
  • I'm not exactly sure what you mean by that. What are you trying to achieve with NETLOAD? – Nik Oct 23 '17 at 18:43
  • I execute NETLOAD to choose the DLL that I want to load into AutoCAD. After loading it, my custom functions are available via the in-app console. – Steve Rukuts Oct 23 '17 at 19:03
  • Right. Correct me if I'm wrong, you are looking for a way to NETLOAD the dll automatically so that your users don't need to think about it? – Nik Oct 23 '17 at 19:12
  • Actually, it's just so I can develop easily. CAD Bloke wrote a description on how to do that as another answer on this question. – Steve Rukuts Oct 24 '17 at 10:10
  • To be honest, I wouldn't recommend going that route (not that there is anything wrong with that, I just don't see a point of creating more scripts when you can already utilize existing methods). See at the bottom of my answer to load the DLL automatically. I would say the registry is your best bet. Set it and forget it! – Nik Oct 24 '17 at 16:09

2 Answers2

5

It is true, the API is indeed large, and some functionality is somewhat poorly documented. I found it difficult to get started, but once I became familiar with the core concept and functionality, I started to very much enjoy working with it as the API very powerful and easy to work with once you "get it". I am not sure what sources you have checked, but I started with this Developer Documentation. Scroll down to the training labs. I would recommend that you at least read through both ObjectARX and .NET Training labs. Spend a few days working through the .NET labs as it will save you countless hours down the line.

As for debugging, the set-up below should give you the most effective and efficient approach (here I use VS 2015 and AutoCad 2015). In the project properties, under the "Debug" tab, your settings should be as follows:

  1. Check "Start external program:" and enter the path of the AutoCad executable. This applies to other versions of AutoCad.
  2. In the "Command line arguments:" field, enter /nologo. This will significantly speed up the start-up of AutoCad.

enter image description here

To load your dll into AutoCad automatically, you can either do it through the registry (my preferred way) or through acad20xxdoc.lsp or acad.lsp (AutoCad will run these scripts by default for each document you open or when AutoCad starts respectively). You can find details in this post.

Now Pressing F5 will start AutoCad and load the debugger. You can now step through lines of code as for any other piece of code. Place a break point at the start of your code, then execute your command in AutoCad. Your break point should get hit.

Aside: /nologo can also be added to AutoCad's Desktop shortcut to speed up AutoCad for users. It can be added to the "Target:" field in the shortcut properties. i.e. "C:\Program Files\Autodesk\AutoCAD 2015\acad.exe" /nologo

Note: A possible Gotcha! Make sure that any AutoCad dlls that your project references have their properties set to:

  1. Embed Interop Types -> False
  2. Copy Local -> False. Also make sure that there are no AutoCAD dlls (i.e. acmgd.dll or any dlls with names starting with "ac") in your Debug/Release directory. Delete any that you find. Not doing so will cause errors and crashes that will be very hard to trace down.
Nik
  • 1,780
  • 1
  • 14
  • 23
2

You can run a script at debug to NETLOAD your DLL with the /b commandline switch.

Add something like the following to the end of what you already have in the Command line arguments text box in Visual Studio

/b "C:\Path\To\Script\AutoNetLoadDebug.scr"

The script called AutoNetLoadDebug.scr has contents are something like 

netload "C:\Path\To\Dll\Your.dll"

Note: there needs to a line feed at the end of that line so it actually runs the command. Make sure you don't have AutoCAD set up to already load that DLL or a different build of it. If you do, launch AutoCAD with a different profile using the /p command line switch.

You can't run anything from the AutoCAD API outside of AutoCAD, the .NET DLLs are just mappings of the unmanaged code deep in the bowels of AutoCAD

I do lots of logging (Serilog), especially in debug. There's also CADtest on Github as well as https://github.com/wtertinek/AcadTestRunner. I tried once to Mock the AutoCAD API. Once. Hence, CADtest.

Protip: try-catch everywhere and watch for nulls but you have probably already discovered that.

Read the AutoCAD Tag wiki and have a look at the other forums and blogs mentioned there, they are goldmine of AutoCAD API knowledge

CAD bloke
  • 8,578
  • 7
  • 65
  • 114