Advice on best route to take within a WinForms .NET application

[squatman]

Hi there,

I have a WinForms .NET application that lists drawings. Within the application I want users to be able to:

• Type a title and click a button to update a dwg attribute with that title

• Click a button to and display the value in a dwg attribute

• Select one or more of the drawings and convert it to PDF

I have all of these things working by adding the Interop.AutoCAD.dll into my visual studio project.

The downside to this is full AutoCAD is needed on the machine and it opens up AutoCAD and the drawings when these procedures are taking place.

I'd mentioned in another forum post is there a way for the application to run in the background and AcCoreConsole was mentioned.

Looking at it it doesn't look like I can reference it into my WinForms application and interact how I currently do, is that correct?

It seems like my application could tell AcCoreConsole.exe to open a certain drawing and then run a script, is that the only way to use AcCoreConsole from my application?

The .NET API seems to work like this in that a .dll needs to be loaded into the drawing and then ran, which doesn't seem a good option for me.

Please can someone confirm my queries above, any suggestions are welcomed.

Thank you.

[Ed Jobe]

When using the .NET api, you can only create a dll that is loaded in the host process. You can use the COM api (reference by the Interop dll) to open documents as a "side database", that is, without the gui. This is essentially, what acCoreConsole does. It only works on one db at a time, but you can call it multiple times in parallel. Since it doesn't have a gui or command line, you can only run it with a script. However, the script can load a NET dll and call commands from that. Your application would simply build a prompt for each dwg to process and send that to a console prompt. As to referencing acCoreConsole, you can only reference exe's that support COM.

[squatman]

Hi Ed Jobe, thank you for the response.

Just as I thought I was understanding the possible ways of interacting with AutoCAD and how they are done, this has confused me slightly.

My understanding so far is:

• .NET API = Class Library (DLL)

Uses references (accoremgd.dll, acdbmgd.dll, acmgd.dll) for AutoCAD or (accoremgd.dll, acdbmgd.dll) for AcCoreConsole.
Drawing opens in host application (AutoCAD or AcCoreConsole), then NETLOAD the DLL and run a CommandMethod contained in the DLL.

A script/batch file/3rd party application can be used to trigger the above events (Open drawing, NETLOAD DLL, run CommandMethod).

vb.Net

Dim doc As Document = [Core.]Application.DocumentManager.MdiActiveDocument
Dim db As Database = doc.Database

• COM = VBA or .Net Application

Uses reference to AutoCAD 20** Type Library (acax23enu.tlb) for VBA or (Interop.AutoCAD.dll) for .Net Application.
3rd party app (Excel or .Net Application) programmatically opens/accesses the drawing file and runs operations direct from the 3rd party app. (e.g. draw a line, populate attribute, print to PDF)
This method sees the AutoCAD application visibly open when the 3rd party app opens a drawing to interact with it.

VBA

Set ACAD = CreateObject("autocad.Application")
Set NewFile = ACAD.Documents.Open("C:\Users\user\Desktop\A3.dwg", False)

vb.Net

Dim acadApp As AutoCAD.AcadApplication = CreateObject("AutoCAD.Application")
Dim acDoc = acadApp.Documents.Open("C:\Users\user\Desktop\A3.dwg", False)

Please let me know if the above is wrong, because I'm still getting to grips with it all.

In your post you say

You can use the COM api (reference by the Interop dll) to open documents as a "side database", that is, without the gui.

From my above understanding "COM api (reference by the Interop dll)" refers to my second bullet point, which as I state visibly opens the drawing. How is this possible to use as you say "without the gui"?

You then continue to say "Since it doesn't have a gui or command line, you can only run it with a script. However, the script can load a NET dll and call commands from that". So to me that is no longer a COM solution, it's actually my first bullet point a .NET API solution.

Please can you confirm my understandings or explain a bit further please.

Thank you.

[Ed Jobe]

In your post you say

From my above understanding "COM api (reference by the Interop dll)" refers to my second bullet point, which as I state visibly opens the drawing. How is this possible to use as you say "without the gui"?

You then continue to say "Since it doesn't have a gui or command line, you can only run it with a script. However, the script can load a NET dll and call commands from that". So to me that is no longer a COM solution, it's actually my first bullet point a .NET API solution.

In the first paragraph, I’m referring to ObjectDBX. Search this forum for code samples to create an axDbDocument. You can do most things with the database except things that require a gui, like creating SelectionSets. Instead, you have to iterate modelspace.

In the second paragraph, I was referring to using acCoreConsole. See the link to the Swamp that I gave you.

[squatman]

Ed Jobe, thanks again for the response.

I see now, there is yet another way to interact with AutoCAD!

I've been searching around and after referencing (axdb23enu.tlb & acax23enu.tlb) I've come up with the following:

Dim acadApp As AutoCAD.AcadApplication
Dim oDBX As AXDBLib.AxDbDocument

acadApp = CreateObject("AutoCAD.Application")
acadApp.Visible = False

oDBX = acadApp.GetInterfaceObject("ObjectDBX.AxDbDocument.23")
oDBX.Open("C:\Users\user\Desktop\A3.dwg")

But the AutoCAD window opens briefly, is that correct?

Thank you.

[Ed Jobe]

Yes, but you only have to open it once. Just open and close a bunch of docs in a loop.

[squatman]

Ed Jobe, thank you for confirming.

I think (hope) now I understand all the ways I can interact with a .dwg.

ObjectOBX/DBX is definitely my preferred method for ease of talking directly from my 3rd party .Net Application to the .dwg, the downside being initial load time of the AutoCAD Application (if not already open) and seeing it completely or briefly depending on if OBX or DBX is used.

It's a shame there isn't an ObjectDBX for AcCoreConsole.

I like the speed and background operation of AcCoreConsole, but it's annoying that a script is needed and then a DLL to be loaded, then your CommandMethod to run. Also with regard to getting variables into the DLL/CommandMethod, is there some way I'm not aware of? All I can think of at the minute is to store them in a .txt, .csv or .json file for example.

Thanks again for your responses, appreciate you taking the time to respond.

[Ed Jobe]

The csv is probably the best way. In the app I linked to, I loaded a dll that extracts xref info and writes to csv. It was very quick. You may also be able to write it to the script you want to run.

[BlackBox]

<snip>

It's a shame there isn't an ObjectDBX for AcCoreConsole.

I like the speed and background operation of AcCoreConsole, but it's annoying that a script is needed and then a DLL to be loaded, then your CommandMethod to run. Also with regard to getting variables into the DLL/CommandMethod, is there some way I'm not aware of? All I can think of at the minute is to store them in a .txt, .csv or .json file for example.

ObjectDBX will process a list of drawings in series, where Core Console will process same in parallel.

It might be annoying to NETLOAD the assembly into each drawing, but you code it in a Script once... and that automagically applies to all drawings being processed (again, in parallel).

As a personal exercise, you should perform the exact same tasks using each ObjectDBX and Core Console, to see for yourself... Spoilers: Core Console will be more efficient.

Cheers

[cicognani]

I've done some experiments with AcCoreConsole some time ago, actually, my information may be a little older, but, as far as I know, AcCoreConsole need a full AutoCAD installation to work, and a full licence as well.
This means that a valid user need to login in the same workstation from time to time, and the machine cannot run completely unattended.
So, a classic plugin working inside an AutoCAD workstation (or connecting via Interop) is still a simple and effective way to accomplish your requirements.
It'd open an AutoCAD session, true, but if don't need to show or interact with the drawings (Editor namespace), you can open and modify the DWG without activating the UI, just use ReadDWG().

Also, I experimented with AcCoreConsole for managing lot of documents in a parallel processing fashion, running individual instances of AcCoreConsole, and it works, but each instance needs a full copy of the user profile on disk, adding a little overhead to the whole process.
At that time, the gain from parallel processing wasn't that much, counting also all the coordination needed between the instances... may be better nowadays...

The problem at hand is very similar to one I faced a couple years ago, when the licencing policies have changed and we found ourselves with the problem of a conversion server often locked with a user account request...
We decided to switch to an external library, able to read/write DWGs and convert to PDF using .ctb files. This last feature was quite important, since many libraries that claim to convert DWG to PDF, do not support .ctb files, thus the result is not as expected.
As a bonus, we discovered that that specific library was much faster in publishing PDF than AutoCAD's publishing...
The costs, also, for the first two years was very low, and the .NET interface is nearly identical to Autodesk's APIs, so it was very easy to port the original application to the new library.
Just a possibility, in the end it costs much less than a dedicated full licence...