Unable to load System.Text.Json.dll 9.0.0.0+ (and/or dependencies) in 2025+

[r.van.der.pijl]

Our .NET plugin has a hard dependency on the .dll mentioned in the title. It gives a very not-helpful exception when trying to load it. We can maybe get away with loading an older version, but that could mean missing methods etc. to deal with.

Directly loading using NETLOAD also gives the exception (see below).

We are looking for suggestions/ideas to load the assembly (and dependencies) regardless.

Command: NETLOAD
Cannot load assembly. Error details: System.IO.FileLoadException: Could not load file or assembly 'System.Text.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
   at System.Runtime.Loader.AssemblyLoadContext.<LoadFromPath>g____PInvoke|5_0(IntPtr __ptrNativeAssemblyBinder_native, UInt16* __ilPath_native, UInt16* __niPath_native, ObjectHandleOnStack __retAssembly_native)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at Autodesk.AutoCAD.Runtime.ExtensionLoader.Load(String fileName)
   at Autodesk.AutoCAD.ApplicationServices.ExtensionLoader.Load(String fileName)
   at loadmgd()

This seems to be isolated to the AutoCAD .NET environment. Directly loading the assembly in the same .NET8 environment (".NET 8.0.21") outside of AutoCAD works perfectly fine.

Older versions of AutoCAD also load the assembly (the .NET framework version of course!) fine, as in no meaningless exception .

We have tried a custom/isolated AssemblyLoadContext, doesn't improve the issue.

We can't use IPC, this is the IPC we want to use.

[Norman_Yuan]

IMO, for Acad2025 and later, since it uses .NET Core (.NET 8 for now), thins have changed from from .NET Framework, which must be installed in the computer as WHOLE package (i.e. all, or nothing), while for .NET Core, application would only requires minimum .NET Core packages, and different applications can have different versions of .NET Core (.NET 5/6/7/8/9/10) and the .NET Core packages that go with the custom application would form a kind of self-contained application package, which would not be impact by other .NET Core applications which may use the same .NET Core components of the same or different versions.

AutoCAD 2025/2026 is considered being this kind of .NET Core application, which built on .NET 8.  So, in general, you should use .NET 8 (or older) packages. I assume that using .NET 9 may work in certain cases, but most likely, it will not, as your case. 

Also, some .NET 8 packages used by AutoCAD already exist in AutoCAD installation, and likely being loaded into AutoCAD (on startup, or on-demand). If you add the package with Nuget to your project, you may want to to set Copy Local to false, or you can set reference to the one in AutoCAD install folder. Again, this could be quite complicated, depending on which .NET 8 components AutoCAD uses and for what purpose (i.e. if/when it gets loaded).

In your case, I would use System.Text.Json.dll 8.0.xx.

[ricaun]

You should always match the major version with .NET Core version, in the AutoCAD 2025/2026 that is .NET Core 8 you should prefer to use System.Text.Json version 8.*, specially because the package/assembly is already part of the Microsoft.NETCore.App.Ref. -> C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.20\ref\net8.0\System.Text.Json.dll

---

@r.van.der.pijl wrote:

We can't use IPC, this is the IPC we want to use.

---

Are you using some public IPC package that uses System.Text.Json, can you share?

I recreate NamedPipeWrapper using JSON to use in my RevitTest project.

• https://github.com/ricaun-io/named-pipe-wrapper-json
• https://github.com/ricaun-io/ricaun.RevitTest

I design in a way to force to use the Newtonsoft.Json if the package is loaded inside the domain, if not gonna use standard JSON Serialize/Deserialize, the System.Web.Script.Serialization for .NET Framework and System.Text.Json for .NET Core.

Should work fine inside AutoCAD, kinda thinking to create AutoCADTest project 😛

[ActivistInvestor]

This usually happens when AutoCAD uses the same assembly, but not the same version of it. 

One way to find out what version AutoCAD is using:

1. Download and install a copy of System Informer (FKA, Process Hacker).
2. Start AutoCAD.
3. Start System Informer.
4. In System Informer, locate acad.exe in the process list and double-click on it.
5. In the dialog that comes up, click on the .'NET Assemblies' tab.
6. Scroll down to and locate System.Text.Json.dll and double-click it, and You will see the version number in the dialog that appears.

On the Net Assemblies tab, you'll see the location of the assembly:

We have tried a custom/isolated AssemblyLoadContext, doesn't improve the issue.

An Isolated ALC should work, but if your managed extension is dependent on other assemblies

that are in-turn dependent on System.Text.Json.dll, then it becomes a bit more complicated, and

requires handling assembly resolution. You don't mention what specifically did not work when

you tried using a custom ALC.

[Norman_Yuan]

Very good tip of using System Informer. Thank you, @ActivistInvestor !

[BlackBox_]

---

@r.van.der.pijl wrote:

Our .NET plugin has a hard dependency on the .dll mentioned in the title. It gives a very not-helpful exception when trying to load it.

---

@r.van.der.pijl - at least you got an exception, it could be worse - you could have been able to build & load without any exceptions only to find out that it only works for those with the newer dependency version installed. I had to learn the hard way, by sharing a 'working' app, that those without NuGet, etc cannot run it:

https://forums.autodesk.com/t5/net-forum/net-8-migration-system-drawing-common-error/td-p/13811252

---

@ricaun wrote:

You should always match the major version with .NET Core version, in the AutoCAD 2025/2026 that is .NET Core 8

---

Also, thanks for sharing that advice, @ActivistInvestor.

[r.van.der.pijl]

The assembly is, despite what the version suggests, a .NET8 assembly. I have mentioned this in the original post. Even .NET framework has a 9.0.0.0 version of the assembly, which loads fine in AutoCAD 2024

[r.van.der.pijl]

The assembly is .NET8, but its version is simply newer than the only loaded into AutoCAD2025 by default. That should work fine, as .NET can load multiple assembly versions and their dependencies simultaneously. Especially when using an AssemblyLoadContext. It loads in a standalone .NET executable using the same .NET environment, so it seems to be some loading error caused by AutoCAD itself.

The IPC we use is ServiceWire whose NuGet package defines a minimum version of 9.0.0.0. We use this package in multiple places of our software without issue.

[r.van.der.pijl]

The version AutoCAD uses is older. We can apply custom assembly loading and simply force the older, already loaded assembly to be returned instead. We mentioned this in the original post as potential solution, but find it very hacky.

That tool is very nice, thanks for suggesting!

When attempting to load the assembly (or one of its few dependencies) in a custom ALC, the exception is exactly the same.

[ricaun]

---

@r.van.der.pijl wrote:

The assembly is .NET8, but its version is simply newer than the only loaded into AutoCAD2025 by default. That should work fine, as .NET can load multiple assembly versions and their dependencies simultaneously. Especially when using an AssemblyLoadContext. It loads in a standalone .NET executable using the same .NET environment, so it seems to be some loading error caused by AutoCAD itself.

---

By default an .NET Core application gonna load all the assembly in the default AssemblyLoadContext, and I believe AutoCAD does not create a AssemblyLoadContext for your AutoCAD Addin. So in that case if AutoCAD already have the System.Text.Json version 8.* loaded and your Addin uses version 9.* a classic dependencies conflict could happen.

---

@r.van.der.pijl wrote:

The IPC we use is ServiceWire whose NuGet package defines a minimum version of 9.0.0.0. We use this package in multiple places of our software without issue.

---

You could try to use ServiceWire Version 5.5.4 that uses a older version of the System.Text.Json just to test if your AutoCAD Addin works.

[ActivistInvestor]

---

@r.van.der.pijl wrote:

When attempting to load the assembly (or one of its few dependencies) in a custom ALC, the exception is exactly the same.

---

This is most-likely because your AutoCAD extension is being loaded into the default ALC rather than the custom, isolated one you are creating.

My suggestion is to divide your extension into two parts. The first assembly (let's call it the 'loader') is what AutoCAD loads into the default ALC. That assembly contains no dependence on ServiceWire. Then you create a second assembly that has the dependence on ServiceWire (call this the 'ServiceWireClient'). Then, when AutoCAD loads the 'loader' assembly, it creates the isolated ALC and loads your ServiceWireClient, ServiceWire, and System.Text.Json v9.0.

I goated ChatGPT into sketching this out, because I don't have the time to do that. You can have a look at this conversation.

[kerry_w_brown]

Tony, Thanks for your excellent reply.
It's a pleasure to see 2 such well crafted ChatGPT prompts and the resulting response.

Regards,

Live long and prosper,

[Darin.Green]

@r.van.der.pijl Try removing all system assemblies from the folder where you plugin dlls are located.  If they're in that folder, it'll attempt to use them instead of the assemblies within .NET Framework.

Once removed, try loading your plugin with netload again

i.e. Remove these types of assemblies...

[soonhui]

I do think that the real solution can only happens on AutoCAD side, I've opened up a ticket, so please consider giving it an upvote

https://forums.autodesk.com/t5/civil-3d-ideas/support-different-assemblyloadcontext-internally-withi...

It's in Civil 3D ideas beacuse AutoCAD doesn't have a similar ideas forum.