@ricaun , thank you! What about Civil 3D 2027 and AutoCAD 2027 in general?
Yes, AutoCAD 2027 should be .NET 10.
AutoCAD should use the last LTS version available as well, in the end of the year .NET 8 is deprecated so would be strange to release a AutoCAD in that version.
@ricaun , on a related topic, do you think that Revit (or AutoCAD/Civil 3D) 2026, which is assumed to be built with .net 8, can host .net 6.0 plugin? Forward compatibility may not be possible ( ie: if host is .net 8.0 the plugin cannot be .net 10), but what about backward compatibility ( if the host is .net 8.0 and the plugin can be .net 6.0)?
Is kinda tricky to have a plugin build with net6.0 because Revit does not have a RevitAPI.dll build in net6.0, the compiler gonna complain if you try to use the net8.0 RevitAPI.dll reference in a net6.0 project.
Is more realistic to use net8.0 (Revit 2025-2026) and net10.0 (Revit 2027) as example, if I create a simple plugin for Revit 2025 using net8.0, with a ribbon panel with a button to delete all walls. The same assembly should work fine in Revit 2027 that is net10.0, assuming that my code is not using any deprecated stuff in Revit API.
Usually if you build your code to net8.0 should work in all future versions of .NET core.
@ricaun , I agree with you that it should, but it's not guaranteed.
Because we have AssemblyLoadedContext issue, and even if we don't have that, it's still not a given I afraid; my hunch is that this just needs careful testing. So I have opened an Civil 3D ideas and hope that someone looks into it.
@nagahhh wrote:Because we have AssemblyLoadedContext issue, and even if we don't have that, it's still not a given I afraid; my hunch is that this just needs careful testing. So I have opened an Civil 3D ideas and hope that someone looks into it.
That's a dependency problem subject, or dll hell problem. That's nothing to do with the target framework, if your package is net6.0 or net8.0 does not matter, the window application will resolve exactly the same.
Usually Autodesk take some time to fix stuff and when happen it only affect future versions of Autodesk products, I prefer make my plugins without the issue using some workarounds.
The ultimate workaround to fix the dll hell is to Repack the dependency dll in your main addin (or create your own dependency dll) using ILRepack. I create a package to make that Repack process easier when building the project, and that should work in NET Framework or NET Core.