Rhino 8: C++ DLL procedures not found, works fine in Rhino 7

Rhino Developer
,
1

Hi,

I have a C# Grasshopper plug-in that calls functions from a C++ DLL the normal way through declspec exports on the C++ side and DllImport on the C# side. I have added the build path of this plug-in and associated dependencies (including the C++ DLL) to the list under GrasshopperDeveloperSettings.

It works perfectly fine in Rhino 7.

When trying to use the same plug-in in Rhino 8, it throws “Unable to load DLL… The specified procedure could not be found.” All components in the same plug-in that only use functions that don’t reference this DLL load and work properly.

So, it seems that it finds the DLL alright, but cannot find the appropriate functions.

Has something changed in the way that Rhino loads libraries and their dependencies? Is it something to do with the shift from .NET Framework to Standard? Something to do with certificates and security?

Any tips appreciated :slight_smile:

2

Upon some digging, it looks like it’s a dependency clash:

Rhino 8 has a dependency on openvdb.dll because of Cycles. My plug-in also uses OpenVDB, probably a different version of the one included with Cycles, and therefore also has openvdb.dll in the build path. Since it is probably a different version - it can change - the function calls are probably also different. Or else the version of openvdb.dll somehow otherwise conflicts with my version of it.

EDIT: Confirmed. When moving openvdb.dll out of the Rhino 8/Plug-ins folder (thus preventing ccycles from loading) my plug-in works.

Is there any way to ensure that the DLL that my plug-in targets is not the one that Rhino loads for Cycles?

1 Like
3

perhaps rebuild your openvdb.dll such that it is not called openvdb.dll but say openvdb_ts.dll and then link to and load that instead?

4

But I don’t want to rebuild OpenVDB :sob:

Yeah, I guess that’s the only way :slight_smile: Unless, do you know which version of openvdb.dll Rhino 8 is shipping with currently? Perhaps it can help if I use the same version.

5

instead of rebuilding it maybe rename it and use dumpbin to change the linking in your dll that has openvdb as dependency. I did something like that for OpenImageIO DLL to get rid of dependency on dbgeng.dll - I essentially had a differently named DLL as the dependency then used dumpbin to change the OpenImageIO DLL without having to rebuild it.

edit: after digging in my memory what I did was create a stub dll with a name that has same length as the dll I needed to replace. Then I manually ( :open_mouth: ) edited the depending DLL in an hex editor and replaced original dependency name with the new one. This may not be as nice as you want.

The OpenVDB version we use is 10.0.0. Here some defines from the version.h of OpenVDB:

#define OPENVDB_LIBRARY_VERSION_STRING "10.0.0"
#define OPENVDB_LIBRARY_ABI_VERSION_STRING "10.0.0abi10"
#define OPENVDB_LIBRARY_VERSION_NUMBER 167772160
1 Like