Conditionally link the RhinoCommon.dll v5 or v6

Hi everyone, I’m developing a plugin for my company that appears to be working both for Rhino 5 and 6 with no changes (I’m looking at you, TODO tag in Rhino - What's New?).
I’m using the C# API on Windows (having VS as IDE). Thing is, I’d like to load one of the two different versions of the RhinoCommon.dll depending on which external program I’m running the code with (In VS ->debug ->properties → Debug tab → start external program).
The code I wrote looks like this:

public class MyPlugIn : PlugIn {

   protected override LoadReturnCode OnLoad(ref string errorMessage)
            var v = Rhino.RhinoApp.ExeVersion;
            if (v == 5)
                Assembly.LoadFrom("C:\\Program Files\\Rhinoceros 5 (64-bit)\\System\\RhinoCommon.dll");
            else if (v == 6)
                Assembly.LoadFrom("C:\\Program Files\\Rhino 6\\System\\RhinoCommon.dll");

problem is that in order to resolve the references to the library I need to specify (obviously) a library at compile time. Unfortunately this dll is the one that will be loaded when the programs enters my plugin, essentially once I get into the OnLoad (which, correct me if I’m wrong is the entry point of my plugin) it’s already “too late” and the linking already happened, so I cannot decide which version of the dll to use.
Am I doing something wrong? Is the whole idea stupid to begin with?
Copying the “right” dll into the local path before executing doesn’t seem to be an option since Rhino 6 explicitly doesn’t like this.

@Riccardo_Di_Lorenzo i’m not sure but if you run V5 plug in V6 it will test if it is compatible with V6 rhinocommon and will use V6 rhinocommon dll - @DavidEranen am i right?

You should be able to compile against v5, and still run in v6.

That said, you can edit your project files to reference one or the other based on the selected configuration.

First you’ll have to create some extra configurations, say Release6 and Debug6 as copies from the existing Release and Debug. Then refer to the following link how I do this for GhShaderNodes (Cycles shader nodes for the Raytraced viewport mode in v6). Here I link conditionally against Rhino WIP or Rhino 6 or a local developer build, but the idea should be clear.

Note when you do this that Visual Studio won’t properly show the references in the solution explorer, but it still works fine.

I would stay away from explicitly loading the assemblies like you showed in your original post.


This just won’t work anyways. RhinoCommon for a specific version of Rhino is already loaded before your plugin loads.

Exactly, the only thing I can do is modify the linking target at compile time.
@nathanletwory if I compile with the v5 dll and try to run it on Rhino 6 I get “The plug-in does not appear to be compatible with this version of Rhino” error message by the way, so, no, I have to give the correct dll target.

It isn’t too hard to modify your project files to do conditional referencing.

If you can, please share your plugin with @stevebaer, as it is essentially a bug if a v5 RhinoCommon plug-in doesn’t load in v6.

I would be interested to know what is causing the plugin to be incompatible as I may be able to fix this without any work on your part. Is there any code you get compile errors with if you reference the V6 RhinoCommon in your project?

No compile errors at all, Rhino simply cannot load the plugin when run

I can both compile and run my plugin with any of the two versions, but the annoying thing is that everytime I need to switch version (build the release for different clients) I need to link the correct version of the library.
I can send you the compiled .rhp if needed.

EDIT: Maybe is worth noting that I’m using the evaluation version of Rhino 6.

@Riccardo_Di_Lorenzo the question was if you get compile errors when you explicitly reference the Rhino 6 RhinoCommon assembly. Your screenshot shows Rhino 5 RhinoCommon being referenced.

no, if I reference v6 and run v6 I have no problem, same if I reference v5 and run v5.

You can btw also do a quick check with to see what the tool says about your plug-in when it is compiled against Rhino 5.

It would be useful to receive your plug-in. You could send it in a private message to me or @stevebaer and we’ll have a look.

This may be a bug in our compatibility checker that we can fix. If we can get a copy of your plugin (compiled against V5 RhinoCommon), we should be able to figure out what is going on.

I think that may be the issue. I was able to load your plug-in into V6 SR3 which leads me to believe that we fixed a bug for this between your evaluation version and now. When SR3 becomes the official release the evaluation version will be based on this (probably next week).

When you go to the about page for your V6 eval, what version number does it report?

Version 6
(6.2.18065.11031, 06/03/2018)

That sounds great! thanks a bunch guys, I’ll keep a close eye on this. in the meantime I’ll give a look into my .csproj file as Nathan suggested

Hi @Riccardo_Di_Lorenzo, just to check we’re covering all possibilities… When Rhino 6 attempts to load a Rhino 5 plug-in it actually checks all *.dll files in the same directory as the .rhp plug-in file. Do you ship your plug-in with any accompanying .NET assemblies? If so, do any of these assemblies reference RhinoCommon? I’ve run the compatibility check manually for the .rhp that you sent us against both Rhino 6 SR1 and SR2 and can’t find any issues which makes me think the failure might be occurring elsewhere…

Another thought… When the “The plug-in does not appear to be compatible with this version of Rhino” dialog appears, there should be more information available in Rhino’s command line. Could you try loading your V5 plug-in in Rhino 6 again and copy the contents of the command line so we can take a look?

Hey Will, thanks for your reply, the zip I sent you is exactly what we ship to our customers, the only thing you have to do is move the two folders into /…/Rhino 6/Plug-ins. All the assemlies we use are inside the folder I sent you, which are essentially a shared library (between some of our software) and some math libraries. Not one of those assemblies has any reference to Rhino. I loaded my v5 plugin as you asked and there is no additional info in the prompt:

Mine is just a guess since I’m not an expert on this, might it be that Rhino uses the wrong registry key to determine which dll to link? I have both 5 and 6 installed and (compile with the dll) run my plugin with both versions routinely. Also, I mentioned that my v6 license is eval because I tried to run my plugin with my Rhino 5 license expired once (our zoo server was down) and I could not load it, so, maybe it could be some unexpected behaviur connected to the license… mine is just a wild guess at this point.

Ah, I’m sorry. I only had the .rhp file. I’ll get the full plug-in ZIP from @nathanletwory and keep digging…

On a different subject… have you tried delivering your plug-in using the Rhino Installer Engine?

I sent you our plugin

It’s in the pipeline :wink:

I’ve tried the plug-in that you sent over in several versions of Rhino 6, from SR0 through to my developer build of SR3. Every time it loads fine!

Testing C:\Users\will\Downloads\unpack_into_plugins\AdapaTools\AdapaTools.rhp (and 8 other assemblies) for compatibility...
Compatibility test succeeded in 2.74s
Drag and drop loaded plug-in C:\Users\will\Downloads\unpack_into_plugins\AdapaTools\AdapaTools.rhp

What else is in the path C:\Users\Riccardo\Documents\SourceTree\adapaaps\adapatools\bin\?