We’ve had two cases recently where plug-ins (Evolute and RhinoMembrane, RhinoMembrane and V-Ray) used different versions of the same .dll files and so would not load concurrently. I’m not a programmer but from the conversation with the developers the issue seems to be that while Windows can support different .dll versions concurrently when used by different applications (.exe files) a single .exe (ie. Rhino) can load only one version. In the case of Evolute and RhinoMembrane, we could fix the problem by replacing the older RhinoMembrane versions of the .dlls with the newer ones in Evolute. For RhinoMembrane and V-Ray, this wasn’t possible – neither plug-in would tolerate changing their versions.
This would seem to be an issue for plug-in architecture in general – how to make sure .dll versions don’t collide with another developer’s choice. Is there a generally agreed way to do this? Is this just a statistical problem, ie. as an educational institution we have more/different plug-ins installed where a business environment might specialize and use fewer, reducing the chance of conflict? Is there a reference list of .dll versions in use for a product that developers could provide/consult? Seems like this might help smaller plug-in developers, who are usually the ones who end up having to make changes. Alternatively, perhaps there are scriptable ways/profiles to simplify the Tools–>Options–>Plug-ins process of loading/unloading to manage the selection during start-up, to at least avoid the symptoms.
This is a long way away from anything that I would be concerned about, but I vaguely remember reading something recently that indicated that there is now technical capability in Windows and/or Visual Studio compile or link options to deal with this situation. Maybe the real programmers here will recall seeing the same thing and give more information. I can’t even remember what I was looking at when I came across it. Or maybe I was just having a bad dream.
RhinoMembrane (2.1.2) and EvoluteProTools Academic use different versions of the Intel Math Kernel libraries (11.0.4.1 vs 11.1.1.1). Where they use a .dll with the same name (e.g. mkl_avx.dll) Rhino chooses one version to load (not sure how it decides this). Normally, it’s the older RhinoMembrane version that loads and Evolute reports:
EvoluteMeshingTools.rhp
Unable to load EvoluteMeshing Tools.rhp plug-in: Dependent DLL is out of date.
If I replace the versions in RhinoMembrane with the versions from Evolute, both run. This didn’t turn out to be the case with V-Ray. In this case an overlap on two of the Qt .dlls (Qtcore4.dll and QtGui4.dll), with V-Ray running the older version (4.5.1.0) and RhinoMembrane running the more recent (4.8.5.0), didn’t get fixed by replacing the V-Ray versions with RhinoMembrane versions – V-Ray wouldn’t load. Similarly, going the other way, RhinoMembrane wouldn’t work with the older V-Ray versions.
I’ve been exchanging mail with the Evolute and RhinoMembrane developers and I believe Gerry (RhinoMembrane) is going to work on this when he gets back next week. It just seems like it would be a more common problem as more plug-ins are developed. It doesn’t seem like a construction issue with Evolute and RhinoMembrane; if Evolute knew how to find its own .dll versions then having RhinoMembrane’s versions load wouldn’t be a problem. Again, I’m not a programmer so my theory of how this works is based on the fact that replacing the .dlls, no matter where they are, changes the behavior of the plug-ins when they’re loaded under Rhino, that somehow Rhino provides a common namespace for plug-ins in which two identically named .dlls can’t co-exist (or, at least, be distinctively addressed by the plug-ins that use them).
@stevebaer please let me know if I can be of any help regarding this issue. I think the mkl_avx.dll that @wcmansp mentioned is being loaded by the Intel Math Kernel Library dependent on the type of processor at runtime.
I have fixed ( hopefully but as a temporary solution ) the clash by updating intel Math Kernel to the last version (same version that Evolute uses ) and removed dependence on QT libraries.
Of course this works since the user that reported the issue is only one and I am afraid it will come up again quite often.
Last year I had another problem with Scan&Solve that links again with Intel Math Kernel Library
I’ve mentioned this issue in the ChaosGroup’s V-Ray for Rhino forum. Possibly they, or those who contribute to that forum, will also have some thoughts.
This comes up again in a .dll conflict between the current network version of RhinoMembrane (RhinoMembrane_x64_215_net) and the latest academic version of Evolute Tools Pro (Evolute_Tools_Academic_64bit – 10/19/2015). Evolute uses the latest versions of the mkl .dlls but RhinoMembrane loads first. To get Evolute to run, the matching mkl .dlls in RhinoMembrane need to be replaced with the Evolute versions, to start, but there is also an additional complication, a .dll in RhinoMembrane that doesn’t have a corresponding update in the 10/19/2015 Evolute – mkl_vml_p4n.dll (1/22/2014). Without replacing this, RhinoMembrane will only launch in Demo mode. To get both to work, the RhinoMembrane version of mkl_vml_p4n needs to be replaced by an updated version; Evolute included one in their prior release (7/15/2015) although they don’t use it in the 10/19 release.
Hi all, apologies for reviving this thread, but I believe I am facing the same issue described here, specifically:
I have installed the ArchiCad-Grasshopper Live Connection plugin, which comes with an instance of the Newtonsoft.JSON.dll [1], and I’m testing out the (now deprecated) Leafcutter plugin for reading/writing to Google Sheets, which also comes with a Newtonsoft.JSON.dll [2].
When both these JSON assemblies are present with the Grasshopper libraries folder structure, Rhino crashes once Grasshopper is loaded and starts loading in the assemblies. This error message is thrown to the desktop:
System::Windows::Forms::Application::ThreadException event occured
SENDER: System.Threading.Thread
EXCEPTION: System.MissingMethodException
MESSAGE: Method not found: 'System.String Newtonsoft.Json.JsonConvert.SerializeObject(System.Object, Newtonsoft.Json.JsonSerializerSettings)'.
SOURCE: ArchiCADConnection
CALL STACK
at ArchiCAD.AC_Utility.Object.Serialize_Remoting(Object obj)
at ArchiCAD.Commands.AC_SendDocumentName.<Execute>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ArchiCAD.AC_DocumentManager.<SendDocumentName>d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at ArchiCAD.AC_DocumentManager.<Instances_CanvasCreated>d__c.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
And I’m running these versions:
- Windows 10 Fall Creators, .NET Framework 4.7.1
- Rhino SR14 64-Bit (5.14.522.8390, 05/22/2017)
- Grasshopper 0.9.0076
- ArchiCad 21 5010 INT FULL
- Grasshopper-ARCHICAD_Connection-21-INT-5011-1.0
I do not plan to actually implement the Leafcutter plugin. That said, I would still appreciate a solution for how to deal with this seeming conflict of assemblies.
For what it’s worth: I deleted the dll that came with Leafcutter [1], and replaced it with the one from the ArchiCad-GH Live Connection, which seems to resolve the problem. That said, these assembly conflicts do seem potentially quite problematic.
[1] I will be looking into implementing the newer Google API’s (.NET and Python) for communicating with Google Sheets, so if anyone has any experience with these I’m all ears
I copyied that dll. Unfortunatelly the the authentication does not work.
Solution exception:A(z) „Newtonsoft.Json, Version=4.0.5.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed” fájl vagy szerelvény, illetve annak egyik függősége nem tölthető be. Erős nevű szerelvény szükséges. (A kivétel HRESULT-értéke: 0x80131044)
Hi there I was wondering how to disable the component “warning” messages(orange), when two assemblies share common namespaces??
Warning (CS0105): The using directive for ‘System.Xml’ appeared previously in this namespace (line 27)
the script works perfectly but leaving that message bother me, Thanks!!!
FYI, I was the Project Manager on Leafcutter (it was a Flux.io project). @andheum was the one-man dev team, and I recall that about 18 months after release there was a Google Auth change that rendered Leafcutter inoperable. With Flux now defunct, I’d be happy to see the project revived – perhaps Andrew can chime in here.
