Topic: Compatability of .NET dlls and AutoCAD versions

[Keith™]

If I build a .NET dll that is loaded into AutoCAD, is it compatable with all versions of AutoCAD .. or can it be compatable if it isn't automatically. The reason is I have a few other DLLs that are written in other languages .. VB6 and C++ .. these programs are written version independent. I don't want to port them over to .NET if I don't have to .. preferring instead to build a .NET loader so they can be "in process" ... but if I have to build 4 or 5 different .NET versions, I'll simply have to load the program in process using a few tricks and then force AutoCAD to manage the code.

[jmaeding]

I just went over this with a few people, I had the same question.
The answer was that your .net dll will be good for the typical sets of three acad versions (2007,8,9), unless you have dependencies that are version specific.
Things like the vertical apps sometimes have version specific dlls, like Land Desktop or Civil 3D.
I think the thing to watch for is the "version specific" property in the references properties.

[Keith™]

All I need to do is load an external program into the AutoCAD process. If this requires developing a .NET dll for each version of the program where the SDK changed, then this solution is no solution.

I suppose I will have to utilize rtlMoveMem, CreateRemoteThread and assembly modules to inject my DLL into the AutoCAD memory space to prevent marshalling .. and having to recreate the dang thing every couple of versions of AutoCAD ...

Oh well .. you would think that for those of us who want to manipulate the AutoCAD object at the core, would be able to utilize a more in depth application interface.

[T.Willey]

I'm not sure I understand the question, but I have one dll that I can use in both '08 and '06.  I am able to load, and run commands defined when I only had '06 installed in '08, and I can run dll's compiled against '08's dlls in '06.

[Keith™]

Ok .. let me give a little bit if background ..

I have an ActiveX application that interacts with AutoCAD dynamically, by loading the required AutoCAD objects at runtime. Using this method is a bit more difficult in the design stage, but you don't have the overhead of dealing with specific version changes and you don't have to rebuild the program when Autodesk changes something in the program, as the program loads a reference to the AutoCAD objects it needs, but only when it needs them. Right now this works great except it is built as an executable and as such there is marshalling. My goal is twofold ...

1) eliminate marshalling by loading my application as an activex dll in-process with AutoCAD
2) take advantage of the existing manifest settings in AutoCAD rather than build my own

I don't want to rebuild every few versions because:
a) My clients are paying a premium for the program. This is not a cheap piece of software.
b) I don't want hundreds of mad clients when they upgrade AutoCAD and their program does not work.
c) I don't want to give away free upgrades to clients using prior versions.

There are many other reasons too.

[Glenn R]

I have .NET dll's that work in 2006 - 2008 and would probably work in 2009 as well.

What actually happens, is that acad spins up an 'AppDomain' to load all .NET runtime extensions into. If you set you're 'Copy Local' setting to false, once you're dll is loaded
into the acad AppDomain (either through NETLOAD or demand loading) it will then probe for the dll's it references ie. *mgd*.dll.

These acad specific dll's are already loaded by the acad AppDomain that has already been spun up, therefor, your dll's can find the references as acad takes care of it.

[sinc]

Note that you can't do any of this if you load the interops, and are working with ActiveX objects in .NET (as you must if you are programming a vertical app like C3D).

With that, there are still ways to create version-independent DLLs, but they involve something called "late binding", which makes your development much harder and slower.

Basically, late binding amounts to replacing lines like this:

Code: [Select]

double rot = entity.Rotation;
with lines like this:

Code: [Select]

double rot = (double)entity.GetType().GetProperty("Rotation").GetValue(entity, null);

[Glenn R]

Agreed. Once COM is involved, you are bound by type library and Interface versioning issues.

[Keith™]

Late binding isn't an issue, I already do everything through late binding ... makes the code version independent. I am deploying to users from R2000 through R2009 ... and yes I know there is no .NET prior to R2004 ...

Anyway, I have about 15 COM exposed classes that already do everything I need done. I am just looking to determine if it would be in my best interest to build a .NET loader for the newer versions of AutoCAD. We will likely be dropping support for AutoCAD prior to R2004 with the next upgrade cycle.

I decided long ago to forgo the ARX development debacle. If I can't move a dll from version to version without having to recompile, I don't want to use it. What happens when users upgrade AutoCAD in the middle of our upgrade cycle? Our users are screwed until we can rebuild the program using the newest SDK.

Nope .. not gonna do it.

and if I can't get .NET to do it, I'll make my own and force AutoCAD to eat it.

[jmaeding]

what do you mean by a .net loader?
That is normal practice to wait for third party developers to create a new prog for each 3 versions of acad.
I'd never complain if a vendor took a month after release to kick out a new compile.

[Keith™]

what do you mean by a .net loader?

An assembly that would load my program into the AutoCAD memory space. Perhaps you have a different name for it. Essentially it is no different than the autoload functions of lisp. All they do is load the other program into memory.

That is normal practice to wait for third party developers to create a new prog for each 3 versions of acad.

It is also one of the reasons why my decision to purchase 3rd party software is based largely upon whether I will be required to upgrade when I upgrade my software. My package works on all windows 32 and 64 bit OSs without issue and works on all versions of AutoCAD from R2000 to R2009 with a single build.

I'd never complain if a vendor took a month after release to kick out a new compile.

You would likely change your tune if the software you were waiting on was mission critical and you paid in excess of $15k for it. You would likely expect that it would work regardless and if it didn't, you would be probably be screaming at the vendor within a few hours.

We are not talking about a device driver or a widget that makes life easier. We are talking about something that takes a hundred manhours and turns them into 5 minutes.

Like I said before, if I cannot expect the .NET assembly to work on all versions of AutoCAD currently released (R2004 - R2009), then I will have no choice but to make AutoCAD to load my interface by brute force.

[sinc]

You've kind of lost me.

I think you started out asking about porting C++ and VB6 code to .NET...?  But you are also saying something about a ".NET loader" that, um... loads something into memory?  ...maybe the C++/VB6 stuff?

I'm not really sure what you're asking, or what you are trying to accomplish.  If you are simply trying to load existing C++ and VB6 stuff into memory, I'm not sure why or how you're trying to use .NET.  If you need to provide .NET programmatic access to C++ stuff, then that would be done by creating a managed DLL for your stuff.  If you are merely trying to convert existing working code to .NET, then why are you doing that, since it sounds like you really don't want to?

[Kerry]

< .. >  and you paid in excess of $15k for it. < .. >

We are not talking about a device driver or a widget that makes life easier. We are talking about something that takes a hundred manhours and turns them into 5 minutes.

so he uses it twice and it pays for itself ?
.. thats a pretty reasonable ROI. Seems to me the client could afford to update AutoCAD by the third usage.

[It's Alive!]

Question: to ADN members get an SDK to play with while testing for the release candidates?

Keith, Do you beta test your mission critical applications on new releases of AutoCAD before shipping? Just to make sure something is not broken?

[Kerry]

Question: to do ADN members get an SDK to play with while testing for the release candidates?

< .. >

yes.