topic Re: Choosing a platform for .NET automation in .NET Forum

Choosing a platform for .NET automation

Anonymous — Tue, 24 Jan 2017 23:16:26 GMT

Hi, new to the forums and hoping for some guidance.

We are looking to add some automation to our DWG creation/management processes, but are not sure what API/SDK/etc is appropriate.

To get started our first goal would be to be able to open DWG files and read/write certain parts such as the "title blocks" sections text contents.

We have existing C# .NET custom desktop applications (WPF) we are wanting to add the features to and the users would also have AutoCAD installed on the machines.

We also want to avoid taking on a huge licensing fee such as with "RealDWG" so we are looking for the lightest footprint for our desktop applications memory usage and our budget. Preferably something that comes with AutoCAD as we already pay for many of those licenses.

We are using AutoCAD and AutoCAD LT 2016, soon to go to 2017 (we upgrade every 1-2 years). Another thing I was hoping (low priority convenience) would be that would wouldn't have to redeply our custom program every time with new DLL's... if the new AutoCAD software is somewhat backwards compatible with older versions of the chosen API/SDK (maybe with breaking changes only requiring it)?

From my limited research I was leaning towards ObjectARX or ActiveX, whichever is lighter footprint and better performance if they both (or another) can achieve the basic needs.

Thanks in advance!

Zack

Re: Choosing a platform for .NET automation

dgorsman — Tue, 24 Jan 2017 23:41:09 GMT

You cannot automate AutoCAD LT.

Without RealDWG you are limited to working with a plugin for AutoCAD or driving it from the outside. The former is the usual preference.

This part:

We have existing C# .NET custom desktop applications (WPF) we are wanting to add the features to and the users would also have AutoCAD installed on the machines.

... is a bit confusing to me. Do you have stand-alone EXE applications which already drive AutoCAD? Or WPF-using plug-ins? Or...? You cannot use the managed dotNET API outside of AutoCAD.

You will need to deploy different DLLs with some versions, typically when there is a "binary compatibility break". For example, I've run the same DLL with AutoCAD 2008 and 2011, but had to rebuild for 2014. The rebuild was basically nothing, re-pathing a couple of dependencies (and a few improvements while I was in there). Its always a good idea to have *some* kind of standard method for rolling out DLLs to users, whether its a stand-alone updater EXE (what I use), a master load plug-in which checks for newer versions before loading them (somewhat common, and can also include some internal licensing/security checks), or a simple BAT routine that runs every time the user logs in.

ObjectARX is fairly heavy to implement, more so than the managed C# dotNET API. Unless you have a full fledged plug-in application in mind the latter is probably better. ActiveX/COM should probably be avoided if possible; if you are driving AutoCAD from an external EXE that's your only option. You might want to consider LISP (yes, yes, I know - heresy! ) but it is *very* light, quite capable within its scope of light automation, is fairly version-proof, and is easier to host and load from a central server location.

You might also want to have a peek at the Core Console. Its a headless (no user interface) version of AutoCAD which supports some limited scripting. Ideal for fully automated, behind-the-scenes type tasks.

Re: Choosing a platform for .NET automation

norman.yuan — Wed, 25 Jan 2017 15:04:20 GMT

@Anonymous wrote:

... I was leaning towards ObjectARX or ActiveX, whichever is lighter footprint and better performance if they both (or another) can achieve the basic needs...

When you say ObjectARX, I hope you mean ObjectARX .NET APIs, not ObjectARX C++ APIs. When .NET API first came out more than 10 years ago, it was merely a .NET wrappers of ObjectARX, hence "ObjectARX .NET API". While it is still the case mostly, Autodesk said it would not limit .NET API only as OBjectARX wrapper. There could be .NET APIs built on its own (without ObjectARX counterparts), and many AutoCAD verticals have already done so, such as AutoCAD Map's platform API are .NET only.

While you probably can get most, if not all, of your needs done on .NET platform locally (most likely in the form of AutoCAD plug-ins, very occasionally external exe automation via COM/ActiveX - I'd avoid it whenever it is possible), Autodesk's cloud services (or other cloud services) may be worth taking into account.

Re: Choosing a platform for .NET automation

Anonymous — Wed, 25 Jan 2017 16:05:54 GMT

Thanks for your input.

Let me better clarify our initial task.

From our existing desktop app (standalone exe, using C#) we are wanting to basically do the following:

1. Open a DWG file

2. Read from or write to the title blocks (according to business logic in our standalone program)

3. Save (overwrite) the DWG file with the changes.

Preferably we would not be controlling any autocad instances or even needing autocad installed/running to do so.

Somewhere down the road this might include reading/editing more than just title blocks... probably start over at that point somewhat if it requires a heavier API/SDK to do so, but just an FYI.

In other situations we have dealt with in the past such as adding interop DLL's to automate importing data from Excel we have done some controlling of applications outside of our standalone but it does get a little hairy so something that would involve just our program and the physical DWG files would be preferred but not mandatory.

Basically just looking for whatapi/sdk/etc would give us this ability so we can weight the differences.

Re: Choosing a platform for .NET automation

Anonymous — Wed, 25 Jan 2017 16:06:16 GMT

Thanks for your input.

Let me better clarify our initial task.

From our existing desktop app (standalone exe, using C#) we are wanting to basically do the following:

1. Open a DWG file

2. Read from or write to the title blocks (according to business logic in our standalone program)

3. Save (overwrite) the DWG file with the changes.

Preferably we would not be controlling any autocad instances or even needing autocad installed/running to do so.

Somewhere down the road this might include reading/editing more than just title blocks... probably start over at that point somewhat if it requires a heavier API/SDK to do so, but just an FYI.

Basically just looking for whatapi/sdk/etc would give us this ability so we can weight the differences.

Re: Choosing a platform for .NET automation

dgorsman — Wed, 25 Jan 2017 17:45:49 GMT

Ah. Well... uhm... given that, I'd be sorely tempted to recommend you start over, re-using the concept from your existing application. Otherwise if you are constrained to operating outside of AutoCAD you're required to either have an AutoCAD session *and* be limited to the ActiveX/COM interface, or you need to purchase RealDWG. There is simply no other way around it, title blocks or otherwise. Without the RealDWG license you really, really want to be doing stuff from inside the AutoCAD application rather than from the outside.

@norman.yuan mentioned the cloud services, and I keep forgetting about them. They call it the "Forge" platform - not everyone's can of beans but potentially very cool in the future.

Re: Choosing a platform for .NET automation

Anonymous — Wed, 25 Jan 2017 18:08:08 GMT

Thanks again.

I'm thinking a plugin or something to that effect is going to be most appropriate.