.NET Framework 4.8 unusable on ACAD 2025?

[nsandersonMKCFD]

Hi all,

Probably a bit of a dumb question, but I'll ask it anyway.

We have a large amount of .NET Framework 4.8 code that has been happily working on AutoCAD 2021-2024 but now we've been presented with 2025 and obviously the landscape has shifted to only support NET 8 (why no dual interface?)

Obvious question is therefore is there a way to get old Framework 4.8 code working 'as is' on 2025 or do we have to port the whole lot of our plugins and supporting DLLs over to NET 8?  Or is there a way to port only the plugins and have the supporting DLLs still sat in Framework 4.8 if both runtimes are installed? 

I have a feeling this is going to be a l-o-n-g job.

[pendean]

---

@nsandersonMKCFD wrote:

...I have a feeling this is going to be a l-o-n-g job.

---

Indeed. Sorry.

[_gile]

Hi

Some assemblies (DLL) built for AutoCAD prior 2025  (.NET Framework) seems to load and run correctly in AutoCAD 2025 (it depends on the APIs used in the assembly and requires the .NET Framwork to be installed on the machine).

If the plugin does not work or if you want to use the new features of .NET 8, you'll have to upgrade.

You should read this topic.

[Ed__Jobe]

Hi @nsandersonMKCFD 

In addition to what @_gile said, I think you can relax a little. It's not a matter of changing all your code. It's just a matter of getting your project to compile to NET 8 standards. Yes C# has evolved, but mostly, your code should work as long as there are no compile errors and the thread Gile linked to helps you with that.

[Keith.Brown]

I think you will probably find difficulty when you discover that you need to support both versions.  2024 and prior as well as 2025.  

[AVCPlugins]

You can try to run the .Net 4.8 libraries as is. Sometimes it works.
The main problem is that .Net 8.0 is an inferior environment. The most important components have been removed from it. Problems arise when working with the Windows registry, SQL, and computer hardware (WMI). But there is an opportunity to compensate for these shortcomings. You need to download individual libraries as NuGet packages. You can create new Net 8.0 projects, paste the old code into them almost without modification, connect the necessary NuGet packages and run the code under AutoCAD 2025.
The good news is that your Net 8.0 projects can call methods from your other Net 4.8 projects. There is no need to recompile anything. The main thing is that no old auxiliary dlls use libraries that are not in net 8.0.
The bad news is that AutoCAD 2025 already uses several NuGet packages and you need to connect to the project exactly those versions of NuGet that AutoCAD uses, and not the latest versions. When AutoCAD is updated, you will probably have to recompile your plugin.
The second bad news is that another plugin can load other versions of nuGet libraries and you will get a fatal crash of AutoCAD. Compatibility between different plugins is now broken.
The third bad news is that you need to deliver a bunch of auxiliary dlls from these NuGet packages to the computers of all users. And load these dlls from your code when initializing your plugin (or write them to the AutoCAD folder).
And there are still a few things that make it necessary to slightly modify the old source codes.

[nsandersonMKCFD]

Thanks for the information everyone. 

We do have a requirement to support customers on previous versions of AutoCAD so this makes it equally tricky.  Two code bases?  Feels like VB6 to .NET all over again!

I assumed that as they were still including .NET Framework 4.8 in the 2025 install, that things would work as is over a few years transition (.NET Framework 4.8 is supported for the lifetime of Windows 11, after all)

I believe I read that the .NET 8.0 implementation was just going to be a wrapper around the original COM/Framework or was that just the .NET 6.0 beta in 2024?  They seem to have broken a lot in one ill-conceived shift?

Yes, our mix of VB.NET and C# Framework 4.8 code refuses to get going in 2025 but works absolutely fine in 2024.so I suspect a heavy porting project is about to get scheduled! 

2025 crashes out quite spectacularly as it fails to find the registered version of a particular DLL.  Perhaps it is as @AVCPlugins says, "Problems arise when working with the Windows registry, SQL,..." which that common DLL does a lot of.

Thanks for the information - I feel a costly meeting with my boss is required!

[AVCPlugins]

>> Two code bases?

No way! As with past API incompatibilities, you simply create multiple projects for different DLLs. All code is pasted into all projects as links. Next, you configure the launch of the desired DLL depending on the version of AutoCAD in the PackageContents.xml file or in a separate start DLL compiled under Net 4.8. This way I have the same code working for different versions of AutoCAD and BricsCAD. The code will sometimes contain directives to the compiler, for example:

#if NET8_0_OR_GREATER
using RegistryKey = Microsoft.Win32.RegistryKey;
#endif

or

#if NET8_0_OR_GREATER
Process.Start(new ProcessStartInfo(AdminMailTo + subj) { UseShellExecute = true });
#else
Process.Start(AdminMailTo + subj);
#endif

>> I assumed that as they were still including .NET Framework 4.8 in the 2025 install, that things would work as is over a few years transition.

No. Some utilities that come with AutoCAD still work on Net4.8. But AutoCAD will never support this again.

>>I believe I read that the .NET 8.0 implementation was just going to be a wrapper

No. The idea of Net 8.0 is so that all code can be more easily recompiled for Unix (OS on Linux, Andriod, MacOS, etc.)

>>They seem to have broken a lot in one ill-conceived shift?

Yes, Microsoft did a great despicable thing. But still, they ported some libraries intended only for Windows to Net 8.0. For example, WinForms works great. Other libraries have been forgotten for some reason. I don't see the logic. Microsoft has all the sources for working with the Windows registry. What prevented them from emulating this work under Unix, like WinForms is emulated? Nothing stopped them.

>>I suspect a heavy porting project is about to get scheduled! 

Yes. I spent about a month on this. However, it’s easier for you - all the problems are already known. In addition, Autodesk announced the change to Net almost a year ago. We've all had time to play around with the beta. My plugins were republished in the AppStore on the release day of AutoCAD 2025.

Read my detailed report here (this is a Russian-language Autodesk forum, but Google will help you with the translation)

[nsandersonMKCFD · Accepted solution]

Thanks for all the input.  

We're coming up with a solution to translate all the AutoCAD (including OEM!) and common support DLL projects over to NET 8.  We're going to have to keep 2 versions live as some of our customers are reticent to move off their 2021-2024 AutoCAD software and they pay the bills!

Weirdly, I tried converting one of our AutoCAD DLLs over to NET 8 using the MS Upgrade tool.  After spending quite a while changing all the Windows.Forms gadget references to System.Windows.Forms ones (seriously, what else would it be?) I ended up with 4 errors due to unknown references to 2 of our .NET Framework 4.8 objects. 

After wondering where NET 8 put 'References' (of course it's under Dependencies->Assemblies...) I managed to add in the AutoCAD libraries and the 2 .NET Framework 4.8 DLLs and much to my surprise not only did it accept them but the code compiled too!  Unexpected?