One Code for two Autocad Version

[pbejse]

On a sheet set program, We normally create separate plug-ins for each version Autocad, all because sheet set  has its own specific NET library files (ACSMCOMPONENTS##Lib) and also NET framework version. 

Is there a way we can make just one plugin for two versions that share the same NET framework? say for example

Autocad 2017 and 2018, only thing is, its using different library files ( 21 and 22 respectively)

Adding both doesnt work. 😩 

..
using Autodesk.AutoCAD.Runtime;
// 2017 
using ACSMCOMPONENTS21Lib;
// 2018
using ACSMCOMPONENTS22Lib;
using AcAp = Autodesk.AutoCAD.ApplicationServices.Application;
AutoCAD.ApplicationServices.Application;

Any ideas?

[_gile]

Hi,

While you need to reference different library versions, you need to build one assembly per library version (i.e., have one project per version).

But you can have all these projects in the same Visual Studio solution and only one project with the source code, in the other projects, you simply 'Add as link' the source code files.

But, did you first try to run the assembly (DLL) build against 2017 libraries in AutoCAD 2018 (or later)? Most of the times, it works because AutoCAD does not uses the referenced libraries which Copy Local property is false. it uses the libraries in the Global Assembly Cach (GAC) corresponding to the version. Referenced librries are only used by Visual Studio.

[pbejse]

---

@_gile wrote:

While you need to reference different library versions, you need to build one assembly per library version (i.e., have one project per version).

---

I see, that confirms what i already been told.

---

@_gile wrote:

But you can have all these projects in the same Visual Studio solution and only one project with the source code, in the other projects, you simply 'Add as link' the source code files.

---

Thank you Gile, that is how i had it now. 

---

@_gile wrote:

.. But, did you first try to run the assembly (DLL) build against 2017 libraries in AutoCAD 2018 (or later)? Most of the times, ..

---

Yes, I did try that after reading your post here  

Thank you for your quick response 👍

[norman.yuan · Accepted solution]

If your code only deals with pure .NET APIs, then, as @_gile suggested, you can try to reference the older version of .NET assemblies to build your code, and the chances are your app would most likely also work with later versions of AutoCADs.

However, since your question is specific about using SheetSet API, which is COM API (you set references to the COM type library and VS generates COM Interop .NET assembly as reference), then, no, you do need to build separate DLL as your Acad add-in for different MAJOR versions of AutoCAD, because each MAJOR version of AutoCAD registers the same classes in SheetSet models with different ClassId in Window Registry.

If you really want to only have a single version of your app, you can use late binding: your first develop your code with earlier version of SheetSet COM API type library referenced. Once the code is debugged, you remove the reference, fix all the explicitly declared types in SheetSet model into "dynamic" (assuming you are using C#), until the code can pass the building. There may be some tricky things to do, but it would the way to work with multiple version of COM APIs.

[pbejse]

---

@norman.yuan wrote:

...If you really want to only have a single version of your app, you can use late binding: your first develop your code with earlier version of SheetSet COM API type library referenced. Once the code is debugged, you remove the reference, fix all the explicitly declared types in SheetSet model into "dynamic" (assuming you are using C#), until the code can pass the building. There may be some tricky things to do, but it would the way to work with multiple version of COM APIs.

---

Thank you Norman

That is something i'm interested to learn. Is there a web page i can look into so i understand this better?

[Anonymous]

Wrong account.

[_gile · Accepted solution]

Hi,

The C# dynamic type is mainly a simple way to use 'late binding', in other words, the type of objects is determined at execution time (the same as with LISP). You can see this topic. The inconvenient when using the dynamic type is that you loose the Visual Studio helpers related to strong types as intellisense and errors on compilation/edition time.

The following simple example illustrates the method @norman.yuan described to replace strongly typed COM by dynamic type to be able to remove COM references.

You first build and debug your project using COM references and strong types in your code.

Then you simply comment the using instruction(s) related to AutoCAD.Interop so that Visual Studio find and displays all type errors

You can now replace the COM types by the 'dynamic' keyword and remove casts to COM types

Note, if the code uses COM enumerations, you should also have to replace the enum memeber by the corresponding integer (eg acActiveViewport = 0, acAllViewports = 1).

You could also have use the 'var' keyword to let Visual Studio infer the type of objects which are properties of a dynamic one.

This done, if the code still work as expected, you can definitively remove the references to the COM libraries.

You can also use the Dynamic Language Runtime (DLR) to write code the same way as we do with 'dynamic languages' such as AutoLISP.

[dgorsman]

Another option I've used for handling this type of situation, is to fork a branch in the source control.  Common changes can be propagated to relevant branches while maintaining required uniqueness.