Reference DLL from installed application

Questions & Answers
1

I’m trying to reference some DLLs which expose APIs to an installed application (Rhino 3d). These DLLs target .Net framework 4.5, and work on both Windows and macOS when developing plugins for said application. We have an example which loads one of the DLLs (by copying it to the project Assets folder) and uses the API. The example is here: rhino.inside/Unity at master · mcneel/rhino.inside · GitHub. While this works, copying the DLL to the Asset folder is not a solution we see viable going forward. The audience that will use this will have both Unity and Rhino installed, so we need that the Rhino DLLs stay in place.

While trying to extend the example, I’m having issues referencing another DLL. If I copy this DLL to the project Assets folder, Unity tries to load it, but it cannot resolve its dependencies. In the Unity console I see that the DLL cannot be loaded and it lists the dependencies with an error that it cannot find the dependency OR the dependency is not compatible.
I’ve tried other ways to load this dependency, for example with Assembly.LoadFrom() which seems to work ok, but then I will have to reflect any part of the API that I need to use.

My application assumes the user is running Unity on Windows and has Rhino installed. For now I’ve been testing on Unity 2018.3.

Before going further, I’d like to ask:

  1. Can one reference DLLs for a Unity project WITHOUT copying them to the Assets folder? I’ve seen the documentation refer to csc.rsp for including other DLLs, but I am not sure if this will work with DLLs not in GAC. I’ve tried an assembly resolver, creating an event handler to catch resolving issues, but it seems by the time I add this code, Unity already complains that it cannot find the dependencies needed by the DLL.
  2. If there is no other way than to copy it to the Assets folder, what is a reasonable approach to resolve any potential dependencies a DLL might have?

Thanks!

2

In my particular case, I was trying to use the Rhino.Inside technology to have the RhinoCommon and Grasshopper APIs running next to the Unity APIs. The sample developed to run Rhino.Inside.Unity, which exposes a simple function to create a NURBS surface from a series of points (defined as spheres in Unity) works probably due to the fact that the code needed to create that surface is native, and thus, the Mono Runtime should be able to access it (since the DLL path is added as an Environment Variable). The Grasshopper API depends on other DLLs. While all of these DLLs could theoretically be copied, you would be coding one API from Mono, and seeing Grasshopper hosted on .Net, and the two would never know about each other. For further information on this particular case, see the post on this issue: Reference Grasshopper related dlls in Unity and resolve dependencies. · Issue #121 · mcneel/rhino.inside · GitHub

In conclusion, the potential solutions to this issue do away with any of the benefits that one might gain from using the Rhino.Inside technology (having Rhino and Host APIs side by side). Other solutions exists that run Rhino / Grasshopper independently from Unity, and communicate between them via sockets, for example, the Speckle client for Unity, Rhino.Compute + RESTHopper.