Use .net api out of CAD process!!!

[Anonymous]

Hi,Guys,
So far CAD .net API is not working for “out of process”.It's designed only for cad command and we must keyin command then wait for the .net api functions.
offical api help saying:
When you develop a new application, it can either run in or out-of-process. The AutoCAD .NET API is designed to run in-process only, which is different from the ActiveX Automation library which can  be used in or -out-of-process. 
·         In-process applications are designed to run in the same process space as the host application. In this case, a DLL assembly is loaded into AutoCAD which is the host application. 
·         Out-of-process applications do not run in the same space as the host application. These applications are often built as stand-alone executables. 
If you need to create a stand-alone application to drive AutoCAD, it is best to create an application that uses the CreateObject and GetObject methods to create a new instance of an AutoCAD  application or return one of the instances that is currently running. Once a reference to an AcadApplication is returned, you can then load your in-process .NET application into AutoCAD by using  the SendCommand method that is a member of the ActiveDocument property of the AcadApplication."

Well, Do we have to send command to use CAD .net api? Is there any other ways to call api function in a independent ExE or dll programm? I have a programm which must be write out of CAD'  process. Of course, the com ActiveX is the best choice,But its function is so limited.Such as DrawJig,Creating nurbs Curve and so on.So I am looking for a way to use CAD .net api by "out of process".
If you have any idear about this. Please advise,Thank you in advance.

[norman.yuan]

While AutoCAD .NET API cannot be used DIRECTLY in "out-process", you can certainly use it INDIRECTLY, in different ways.

1. You can expose your .NET DLL as COM. with this option, you may run into all the potential troubles COM could result in, such as registering COM server on each running computer with admin privilege required; "dll hell", referring to version compatibility...

2. You can still use COM in your EXE to drive AutoCAD and use some way to "NETLOAD" or auto-load your DLL. Then you can use COM's SemdCommand to start your custom command in .NET DLL; or you can use IExtensionApplication.Intialize() to have the process in .NET DLL started at beginning.

The decision is really depends on your business need and how you optimize your process designing. If the business process needs user interaction to some degree, using EXE to control AutoCAD is hardly a good design (as you mentioned Jig, which is meant for user interaction with AutoCAD editor, and definitely not a good candidate to be triggered from external application).

If the EXE is mainly for drawing file manipulation, you may look into RealDwg, or even AutoCAD I/O, View/Data cloud services. You can also look into Acad console (local version of AutoCAD I/O/ and View/Data cloud services) being driven by your EXE.

[Anonymous]

Thank you Norman.Yuan.I will try to use net to write com. To see if it is the solution for my problem.

[i_bherer]

Hello,

I am running into some similar trouble. I am currently designing an application that must run out-of-process. As Norman described, I first opted for the second option: using COM interop, I start up an instance of AutoCAD from a windows forms .exe, and then use AcadApplication.SendCommand("xxx") to netload my .dll plugin and call my internal commands from there. All of these steps work great.

Here is my problem with this solution: I need to be able to extract data from AutoCAD to my external app. With this method, I have no way to obtain return values or call my internal dll functions. How can I establish communication in both ways? 

I have explored Kean's solution here: https://www.keanw.com/2009/05/interfacing-an-external-com-application-with-a-net-module-in-process-t...

Not only have I not managed to get it to work, but I believe this is the first point you were referring to by "dll hell". This is a deal breaker for me as I will deploy this application.

Anyone have any insights for me? Any help is greatly appreciated!!

Sincerely,

Isaac Bhérer-Constant