Problerm in making AutoCAD Plugins for different AutoCAD Version

[1056960357]

I'm using Visualstudio 2015 and .NET to build an Plugin(an *.dll file) for AutoCAD 2014. and  the Plugin is work fine, But when I load the Plugin to AutoCAD 2016 and AutoCAD 2012 using NETLOAD command, the Program crashed. But when I build the plugin under the AutoCAD2016 and AutoCAD 2012, It Work fine. 

So I question is: Is there any way buid the plugin an time and when it can run in the majority of the AutoCAD Platform?

[_gile]

Hi,

If your code doesn't P/Invoke version dependant ObjectARX APIs or use the COM interface, you should be able to build only two versions: one for AutoCAD versions prior to 2013 and another one for 2013+ versions, otherwise you have to build an assembly per AutoCAD major releases: 17 (2007-2009), 18 (2010-2012), 19 (2013-2014), 20 (2015-2016), 21 (2017) and 22 (2018-?) and per platform (32 / 64 bits)

Anyway, if the code is the same for each version, you can have, in a single solution, one project containing the code source files, and in the other projects, just "Add as link" the source file, so that all projects share the same source.

[Juergen_Becker]

Hi,

the version 2013, 2014, 2015, 2016, 2017 are compatible.

The important thing is that you have to use the oldest ObjectARX DLLs.

For Example:

When you want to create an application for 2015 up to 2017 you have to use the ObjectARX DLL from 2015. That's working.

Except:

When you using the COM API you have to create an application for each version.

When ypu use DLLImport you have to create an method for each version and invoke that methods depends on the version.

That's the way I do it and it work.

For version 2018 you have to create a new application because this version is not compatible.

Regards Jürgen

[1056960357]

But when I bulid an plugin under AutoCAD 2014 using VisualStudio2015, I found that  When I using NETLOAD command load my plugin into AutoCAD2016, I found it does not work fine(no exception and error). And When I debug the Plugin, I found the code as follow is run so slowlly

DB.ReadDwgFile(this.FilePath, FileShare.Read, true, "");
DB.CloseInput(true);

And I don't know why

[ActivistInvestor]

---

@1056960357 wrote:

But when I bulid an plugin under AutoCAD 2014 using VisualStudio2015, I found that  When I using NETLOAD command load my plugin into AutoCAD2016, I found it does not work fine(no exception and error). And When I debug the Plugin, I found the code as follow is run so slowlly

DB.ReadDwgFile(this.FilePath, FileShare.Read, true, "");
DB.CloseInput(true);

And I don't know why

---

What does 'not work' mean?  What is it not doing that is should be doing?

What version of the .NET framework is your project targeting?

[_gile]

---

Juergen_Becker a écrit :

For version 2018 you have to create a new application because this version is not compatible.

---

I do not agree, most of the plugins I wrote the same assembly build targeting .NET Framework 4.0 and referencing AutoCAD 2013 libraries work for AutoCAD 2013 to 2018 (included). You can have a look at the .bundle contents of some plugins I published in the Exchange Apps Store.

The very few exceptions are due to changes in some APIs and require code rewriting but this is not specific to the 2018 version.

[Juergen_Becker]

Hi,

this is what Kean says on his blog.

From a developer perspective the main things to note are that the DWG format has changed, as well as there being a break in binary ObjectARX application compatibility.

http://through-the-interface.typepad.com/through_the_interface/2017/03/autocad-2018-has-been-release...

I think you are not right, but it does not matter.

I write my 2018 apps with new the new Nuget packages. You can find it here: https://www.nuget.org/packages/AutoCAD.NET/22.0.0.

Or you use VS to install the packages.

Regards Jürgen

[1056960357]

I mean, When I run the plugin in AutoCAD 2016， I have to wait for a long time to let the plugin to execute the code as fellow:

DB.ReadDwgFile(this.FilePath, FileShare.Read, true, "");
DB.CloseInput(true);

My Build Target is NET Framework 4.0

Thanks

[ActivistInvestor]

---

@Juergen_Becker wrote:

Hi,

this is what Kean says on his blog.

From a developer perspective the main things to note are that the DWG format has changed, as well as there being a break in binary ObjectARX application compatibility.

---

The quote above from the blog post really has nothing to do with .NET. The file format change has no relevance to API compatibility, and binary ObjectARX application compatibility is mainly related to native C++ based ObjectARX (which will only run on binary-compatible releases). For example, a native ObjectARX library that was built with the 2010 SDK (R18) will run on 2010, 2011 and 2012 without requiring a rebuild. But it will not run on subsequent releases.

For managed code, if there is no dependence on changed APIs, the same assembly might run on multiple future product releases, including those that are not binary-compatible, provided it targets the framework version of the earliest supported release. Note the emphasis on might, as I have seen cases where it doesn't work, even though there was no dependence on changed APIs.