.Net framework support

.Net framework support

BestFriendCZ
Advocate Advocate
6,573 Views
5 Replies
Message 1 of 6

.Net framework support

BestFriendCZ
Advocate
Advocate

Hi all,
I would like to ask if there is exist some official table .Net framework support. Does anybody has information / experience about support .NET 5? Thank you for your feedback

 

...
0 Likes
Accepted solutions (1)
6,574 Views
5 Replies
Replies (5)
Message 2 of 6

_gile
Consultant
Consultant
Accepted solution

Hi,

 

Attached a non-official table for AutoCAD / Visual Sudio compatibilites.

I didn't test it, but .NET Framwork 5.0 should be compatible with all AutoCAD versions.

As you can see in the table AutoCAD versions require minimum .NET versions but are compatible wit later versions.



Gilles Chanteau
Programmation AutoCAD LISP/.NET
GileCAD
GitHub

0 Likes
Message 3 of 6

BestFriendCZ
Advocate
Advocate

thanks for information _gile

...
0 Likes
Message 4 of 6

CZITApplicationsDept
Explorer
Explorer

Hi, I'm afraid it's not so simple.

 

.NET 5 is not .NET Framework. It's a combination of .NET Core and .NET Standard.

The last version of .NET Framework is 4.8. Microsoft will not release any future versions of .NET Framework.

https://devblogs.microsoft.com/dotnet/net-core-is-the-future-of-net/

 

I have build a simplest plugin DLL with .NET 5.0 Preview 3 referencing "acoremgd.dll", "acmgd.dll" and "acdbmgd.dll" from AutoCAD 2021.

I could not load this DLL in AutoCAD using "NETLOAD" command as I got the following error:

Cannot load assembly. Error details: System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type)
   at System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
   at System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments)
   at System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent)
   at System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType)
   at Autodesk.AutoCAD.ApplicationServices.AutoCADApplicationHolder.Initialize(Assembly assembly)
   at Autodesk.AutoCAD.ApplicationServices.ExtensionLoader.ProcessAssembly(Assembly assembly)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

 

It looks like the reflection which AutoCAD uses to discover methods with CommandMethod attribute does not work with .NET 5 libaries.

I got this error regardless of whether I published the DLL as a Self-Contained or Framework-Dependent deployment, so the error does not mean that my DLL couldn't find some reference. The error is clearly coming from AutoCAD codebase as can be seen in the call stack.

 

I would also like to point out that I could successfully run .NET 5 applications outside of AutoCAD on my test machine, just to avoid any comments of type that I don't know how to deploy .NET apps.

 

So, in conclusion, I don't think that current versions of AutoCAD support .NET 5.

We may need to wait for Autodesk to officially support it.

Otherwise they will be stuck on .NET Framework 4.8.

 

It's a bit strange that there is not a lot more activity about this or that Autodesk does not put out an official statement so that developers can prepare.

Message 5 of 6

andreas.fischle
Participant
Participant

Hi,

 

.NET5 is very interesting, but still a rather new technology. It is still in preview and Microsoft announced that it will not be an LTS release (.NET6 will be the first LTS release.)

 

Presumably, Autodesk are currently assessing the impact of this new technology on their products rather intensively (internally), but it might still be a bit too early to publish a sufficiently reliable roadmap regarding the plugin APIs.

 

Many Microsoft technologies relevant to the two Autodesk products that I know (AutoCAD/Revit) were only very recently added to .NET Core 3.1, which is the technical foundation of .NET5. As I recall it, parts of the runtime of .NET5 (Core) actually stem from Mono (Linux). This makes sense, because .NET5 is now cross-platform — up to certain exceptions, e.g., the upcoming WinUI3 and C++/CLI are only supported on Windows.

Now, while the technical foundations have shifted rather fundamentally, the actual upgrade to .NET Core-based targets (incl. .NET5) can be pretty seamless - or so it seems.

 

However, due to this, a. NET Framework runtime cannot load .NET Core assembly .dll-files, as you observed. It is not to be expected. There are indeed changes to how reflection information is stored in the assembly. I believe this was necessary, because .NET5 also supports AOC (ahead of time compilation) instead of JIT, similar to C++. (The other way around, there is a compatibility layer.)

 

There are substantial differences and I also think that large parts of the AutoCAD host application must first be ported to .NET Core, or more precisely .NET 5, in order to load your plugin. That might take a bit of work 😉

 

Since .NET Framework 4.8 is an LTS release that Microsoft promised to keep around forever, my guess is that .NET Framework 4.8 might still be the target framework for the Autodesk plugin APIs for at least one or two years.

 

I am also looking forward to a roadmap regarding the adoption of either .NET Core 3.1 or, more likely, .NET5 by Autodesk AutoCAD/Revit. The performance gains in .NET Core seem very attractive and .NET Framework is now a dead end. It would be good to know how to deal with the latter.

 

The sooner we can plan the efforts and timeframe for porting our plugin products to a .NET Core-based technology for Autodesk AutoCAD/Revit, the better!

 

Best regards,

Andreas

Message 6 of 6

Izhar_Azati
Advocate
Advocate

https://dotnet.microsoft.com/download/dotnet/6.0 

The .NET6 will run on Windows and macOS, but we don't hear from Autodesk.

0 Likes