No problem. I will look further into it and will contact our CAD-support team. If we find the cause and/or solution, I’ll let you know.
1 Like
Try and grab the list of DLLs the add-in brings with it. Duplicated ports is a dependency conflict, so knowing what it uses can quickly narrow things down.
Yep.
I am guessing that NewtonSoftJSON is the most likely culprit as it’s the root cause on similar Revit issues (seemingly 9/10 times). Can you get the version (open the file details)?
@Anton_Huizinga should also do a quick review incase he has other DLLs in use which could be in conflict.
The only fix will be to contact the add-in provider, point out the dll conflict with a feature of the core software they are integrating into, to them and ask for a fix from their end. Dynamo can’t change as it integrates with a dozen other toolsets and has to coordinate across them all (i.e. the version of newtonsoft used here is also used in Revit, Alias, FormIt, Forma, Robot, Advance Steel, etc.) to allow portability of content.
NewtonSoft.JSON is indeed a referenced library. It refers to the one that is provided with the Civil 3D software.
If the ArcGIS connector uses another version, and it loads first, then it can cause a conflict.
Version Newtonsoft.Json.dll in the ArcGis plugin folder: 13.0.3.27908
Which version of Civil 3D is that for?
Civil 3D version 2024.3.
1 Like
Microsoft.Xaml.Behaviors.dll and Newtonsoft.Json.dll show up offhand. Version of newtonsoft seems to align though so it could be a combination of add-ins (welcome to DLL Hell).
I recommend looping in the add-in provider directly even if we can’t find the specific root as they are more likely to be able to reproduce and debug directly.
Alright. I’ll contact our ICT department and add your advice. Hopefully we’ll find a solution or at least a workaround.
Thank you very much for your time and help.
An update on this issue:
It seems the problem only occurs in C3D 2024. We’ve run some tests in C3D 2022 and 2025. Both versions worked fine. At this moment we don’t know exactly what caused the problem, but updating our C3D version seems to be the solution…
I also would like to refer to 2 topics on this forum with similar problems that helped me:
The Arkance Systems Node Library will not load in Civil 3D 2025.1 and higher, you need The Civil Nodes package then. The same issue could occur, but I hope not 
Alright. I’ll ask our IT Department to install the available SP’s and I’ll run some more tests.
Does the “Civil Nodes” package replaces the “Arkance Systems” package, or do I have to rebuild all my routines?
The Civil Nodes package is a new package. It contains about 95% of the nodes from the Arkance Systems Node Library, a few nodes from Camber and a handful similar to C3DToolkit nodes.
The category structure is different so you need to change current graphs.
I think we can automate this if all nodes are the same inputs and names… 
If… but because I was forced to align with the 2025.1 changes, I also made some changes here and there, moving nodes to other sub-categories and some input port changes.
My thought would mean subcategories wouldn’t be an issue, but port changes would require some mapping effort and the scope of the effort grows larger as a result.
Might dig into this next week, but basically a tool to open a bunch of DYNs as text JSON objects, replace the function in the dyn (swap a GUID here, a string there) and then when inputs change deal with the connectors (this is far less fun and would be experimental).
There is a migration tool available in the Camber repo. Perhaps you could use it as a starting point
More info here: