.Net Core / Interop 2025 Standalone command line executable

[silo3]

Hi all, I've been scraping data from this site for awhile, but am diving deeper into formal .Net development. What I intend to do is use .Net core for an out of process executable to read and write into AutoCAD. I understand that previously .Net framework with interop was more universally accepted. 

My question is: is .Net Core a good plan for future development compatibility using the methods outlined here: bridging net core

1. If so, it appears that this is a Netload *.dll program loaded into AutoCAD. How exactly do I link this up with an external executable?
2. Is the external executable program a .Net Core framework and which headers/libraries should I include?

3. I intend to use C#, are there any good sources for documentation or simply scan the ObjectArx samples?

Thanks all for the consideration.

[norman.yuan]

I sounds to me that you are not very into AutoCAD programming (using AutoCAD's LISP API, COM API, .NET API, or ObjectARX C++ API). When you say to create your executable program, I assume you mean a stand-along Window desktop app (with UI built with WinForm or WPF; or simply a console EXE). Then you need to clarify what is to your goal of the app, because "...to read and write into AutoCAD..." is, kind of, unclear: do you mean you app needs to communicate a RUNNING AutoCAD session (in the same computer, basically) in order to get/send data from/to AutoCAD/drawing opened in AutoCAD? Or, "read/write" mainly means the data in drawing (well, to access drawing data, there has to be a flavor of AutoCAD process running, but it is not necessarily be a full desktop AutoCAD session).

Yes, with .NET Core desktop exe, you can Automate AutoCAD session via AutoCAD COM API, as you do with .NET Framework. However, a solution of this kind would be my last possible approach I'd take when there is no other better way to meets the business requirements.

Without knowing the details of what is your business goal, and your knowledge of AutoCAD programming, it is difficult to comment more, but doing something the the linked reference you mentioned is likely not what you want to do.

 SO the short answers to your 3 points:

1. As beginner, if you really have to do stand-alone EXE to get to AutoCAD/drawing data (again, I'd say "DON'T"), you would start with AutoCAD COM API, and forget doing .NET API first and expose to COM;

2. If you have to do the EXE solution, you simply add references to AutoCAD interop COM API dlls, which come with AutoCAD installation (Autodesk.AutoCAd.Interop.dll/Autodesk.AutoCAD.Interop.Common.dll);

3. While one can choose VB.NET or C#, C# would be the wise choice.

[silo3]

@norman.yuan Thanks for the quick response. The intent is to create a console *.exe which is flexible with database/ data table sources. I have been able to cross-link an excel table with a running AutoCAD session, but as the ACAD application is a COM object, I am unsure/unable to access the internals in-process. That is to say that I am loading an in-process *.dll into the AutoCAD session after grabbing the out of -process application. Right now I am simply using code from here:

in process vs out of process 

try {
acAppComObj = (AcadApplication)Marshal2.GetActiveObject(usedProgID);
acDocComObj = acAppComObj.ActiveDocument;
acLayout = acDocComObj.ActiveLayout;

acDocComObj.SendCommand("(command " + (char)34 + "line"+ (char)34 + (char)32 + (char)34 + "0,0" + (char)34 + (char)32 + (char)34 + "22,33" + (char)34 + (char)32 + (char)34 + (char)32 + (char)34 + ") ");

acDocComObj.SendCommand("(command " + (char)34 + "NETLOAD" + (char)34 + " " + (char)34 + "c:/myapps/sheetbuilder2.dll" + (char)34 + ") ");

acDocComObj.SendCommand("shtbuild ");

}
catch {
Console.WriteLine("failed world?");
}

It appears that I cannot access the "component object model" in this way as appears in the documentation/ unable to access the methods and properties of the objects.

2. If you have to do the EXE solution, you simply add references to AutoCAD interop COM API dlls, which come with AutoCAD installation (Autodesk.AutoCAd.Interop.dll/Autodesk.AutoCAD.Interop.Common.dll)

This sounds good although you're very correct when you say I am not familiar with the delineation between the technologies.

Right now the program is developed from the EllipseJig ObjectARX sample code using the COM references: accoremgd.dll, Acdbmgd.dll. Is this using the .Net core? I had to add the Marshal2 class to "Marshal2.GetActiveObject("AutoCAD.Application.25")"

Is interop out-of-process? Which part of the documentation would I refer to? 

https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop

I want to use well documented notation as such to insert blocks/sheets etc. instead of sending commands

https://help.autodesk.com/view/OARX/2025/ENU/?guid=GUID-2656E245-6EAA-41A3-ABE9-742868182821

The reason I am aiming for out-of-process is because I want to run automation and data extraction from the file without user interaction on a virtual machine or remotely.

Apologies for the rambling and much appreciation for the help.🙏

---

[BlackBox_]

Completely agree with @norman.yuan.

@silo3 If AutoCAD or one of its verticals (like Civil 3D) are installed on the remote machine (physical or virtual), then it comes with Core Console (AcCoreConsole.exe). 

Core Console provides a headless environment that supports Scripts (.SCR) with native Command calls, AutoLISP, etc as well as (basically) the entire .NET API... you simply need to launch Core Console, load your Script or NETLOAD your assembly, and invoke the necessary Commands and/or CommandMethods. 

As an added bonus, Core Console can batch process DWG files in parallel.

HTH

[silo3]

Yes, I've used accoreconsole.exe script automation on a project last year. I'm looking to avoid script generation and am seeking the bidirectional communication. I also have experience in COM automation through excel into AutoCAD. I suppose that is the most synonymous corollary I can compare it to. I really need the program to ingest data from the drawing, process it and re-output it into CAD though. Am I missing something?

I think this thread is most similar to my issue, but am unsure of how to implement the code: external exe connection autocad 

interfacing-an-external-com-application-with-a-net-module-in-process-to-autocad-redux.html 

Taking a step back, which part of the developer's documentation deals with interoperability and is my attempt to avoid the .Net framework(?) misguided? I truly want to avoid any technical debt due to a deprecated platform  bridging-the-net-core-and-autocad-2025-exposing-and-using-com-server-components-with-getinterfaceobj... 

Thanks for humoring me. I have a tendency towards analysis paralysis.

P.S. Again, key questions are:

1. Where is the interop developer documentation/ is it segregated from other methods? Are all the methods standardized?

2. Is interop reliant on .net framework as opposed to .net core? Should I be concerned about the difference?

3. Critically, does it allow interrogation of the object model for data extraction?

[silo3]

I've found one of your old sample projects. I'll look into it. I think its what I'm looking for.

External Web Interop example 

[BlackBox_]

---

@silo3 wrote:

I really need the program to ingest data from the drawing, process it and re-output it into CAD though. 

---

This is the line that stands out to me... so do all of that, right there, in CAD.

Without understanding your actual tasks/goals/criteria for why this needs to be an EXE, everything you're communicating in this thread says you're wanting to develop a plugin (DLL class library). If you actually do that, you can still query and act on drawings outside of the editor - fully in the .NET API, as a plugin - by using Core Console.

Why introduce (unnecessary?) overhead to transfer the data back and forth? 

Develop your DLL, launch Core Console use a Script (SCR) to open a target drawing, NETLOAD your assembly, and invoke your CommandMethod(s) as needed. You can obtain (basically) any information the drawing contains, and act on it, right there in Core Console. Another benefit of producing DLL, is that it can be NETLOADed into full session as well. 

Much of Civil 3D's API is still dependent on COM, which we interface with right there in a .NET DLL plugin, FWIW. 

HTH

[silo3]

I feel like I'm phrasing my inquiry poorly. The precise question is if I were to create a tiling optimization algorithm given a certain boundary provided within a cad file which would run through a multitude of scenarios, would it be proper to run it "in-process" within autoCAD or better as a standalone program in c#? Given a space of N, the tiles might equate to 10,000. The algorithm may try out 50-100 different tile formats also. Thanks for the patience.

[BlackBox_]

---

@silo3 wrote:

I feel like I'm phrasing my inquiry poorly. The precise question is if I were to create a tiling optimization algorithm given a certain boundary provided within a cad file which would run through a multitude of scenarios, would it be proper to run it "in-process" within autoCAD or better as a standalone program in c#? Given a space of N, the tiles might equate to 10,000. The algorithm may try out 50-100 different tile formats also. Thanks for the patience.

---

Nah, you're good.

*IF* I'm understanding you correctly - code it all to run in CAD - just do your iterative calculations in memory, select the design pattern with the highest ranking (assumed to be based on some sort of criteria, fewest tiles, etc), then produce the entities associated with that tiled pattern about the boundary once.

Does that make sense to you, or am I way off?

[silo3]

@BlackBox_ @norman.yuan 

Many apologies. I believe I've got it. I was improperly using the Application object between interop(?) and Autocad type library(?) I believe. I have the code running in .net core as a standalone console program. I am still getting a grasp on the terminology. 

I think I understand your statement about iterations in memory. I'll take a stab at it.