Announcement

Collapse
No announcement yet.

.dll conflict with RhinoMembrane

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • .dll conflict with RhinoMembrane

    As an educational institution, we end up installing a lot of Rhino plug-ins. Recently, we came across a .dll conflict between versions of the Qt framework used by V-Ray for Rhino and RhinoMembrane (a structures plug-in); we also had a conflict between RhinoMembrane and another plug-in we use, Evolute. The Evolute conflict we could resolve by copying its versions of the .dll files into RhinoMembrane; the V-Ray conflict we couldn't resolve -- neither plug-in would tolerate the QT versions used by the other; when RhinoMembrane loaded, V-Ray would fail to load. In this case, the RhinoMembrane developer coded around this and released a new version, but had to drop some functionality.

    The summary, from the developer discussion, was that while Windows will support different .dll versions when run by different applications, each individual application (e.g. Rhino) can only run one version of a .dll. This seems to be a structural problem that would affect plug-in development in general. At least as of the initial conversation, there is apparently no generally accepted practice for developers to know which versions of which .dlls are being used by other developers for the same product. The issue was raised in the Rhino Forum (http://discourse.mcneel.com/t/managi...libraries/6943) and Steve Baer, one of the McNeel developers, said he recognized it was a problem and would look into it. The Evolute and RhinoMembrane developers have added some comments in the Forum item; it would be interesting to get comments there from the ChaosGroup, or others who have thoughts on this.
Working...
X