Intermittent compatibility issues

Hello all,

Apologies if a similar topic exists, but I haven’t been able to find anything quite like this on here. I’m running into an issue moving my plugin (Pachyderm) over to Rhino 6. I have set up Visual Studio so that it outputs both a Rhino 5 and a Rhino 6 version. Only two code files differ between the two projects. So far so good!

The project builds, and sometimes it starts in Rhino 6, no issues. Other times, it either does a 12 second compatibility check and rejects the plugin, or just claims that the plugin is incompatible with Rhino 6. What gives?

This is pretty frustrating. Could someone please tell me what the compatibility check is looking for, and maybe share any insight into why this might be happening, and what I can do to eliminate it altogether?

Thanks in advance!


@will do you know why the check could fail while at other times it succeeds?

Hi @Arthur,

If you’ve recompiled your plug-in for Rhino 6 then the compatibility check shouldn’t run when the Rhino 6 version of your plug-in is loaded in Rhino 6. The check should only run when the Rhino 5 version is loaded in Rhino 6.

How are you loading the plug-in? Directly from bin directory after compiling?

Hi Will,

I am loading it from the bin/debug or bin/release directories. When I install it from deployment, I put it in a Pachyderm directory in program files, and the same thing can happen there as well.

The two projects differ primarily in which Rhinocommon.dll file they reference. The v5 one references the Rhinocommon file from Rhino V5 X64. Natrually, the v6 one references the Rhinocommon file from Rhino V6. This also led to code changes in two of my files, so I know that my V6 version is referencing the right version of Rhinocommon. Given that, I don’t think that the check is happening in response to a plugin that is not compiled for V6…

I also deploy a version for grasshopper, which I have found does not need to be compiled again for V6. Could that be triggering the check? (the check happens before grasshopper loads, so while I guess this seems like a possibility, I defer to you…)


Thanks for confirming. Can you send the compiled plug-ins to me for testing? Both versions, if possible. Either via discourse or to

By the way, this “compatibility” feature is supposed to make it easier to load plug-ins from earlier versions (where the plug-in doesn’t use any parts of the SDK that were “broken”). I’m sorry that it’s causing you issues with your re-compiled plug-in!

If you have build targets specifically for v5 and v6 you should also have separate build paths. That way you won’t overwrite the plug-in with the ‘wrong’ version.


Thanks. I will, the next time it happens, which shouldn’t take long.

Nathan: I gave the V6 version separate bin/debugv6 and bin/releasev6 folders. Got it covered!


1 Like

@Arthur Quick question – which service release of Rhino 6 are you running?

The latest. I think that is 6, right?


1 Like

@Arthur the version of Pachyderm that you sent over was compiled against RhinoCommon 5 (SR 12). This is why the compatibility check was triggered.

$ /c/Program\ Files/Rhino\ 6/System/Compat.exe ~/Downloads/FailedPach/Pachyderm_Acoustic.rhp | head

Pachyderm_Acoustic, Version=, Culture=neutral, PublicKeyToken=null

Assembly references:
  mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
  RhinoCommon, Version=5.1.30000.16, Culture=neutral, PublicKeyToken=552281e97c755530
  System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
  System.Drawing, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
  Pachyderm_Acoustic_Universal, Version=, Culture=neutral, PublicKeyToken=null
  Hare, Version=, Culture=neutral, PublicKeyToken=null
  System.Numerics, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

This is why I suggested the build locations per target. Perhaps double check this goes as expected.

Also, I’d set the references to v5/v6 RhinoCommon with project conditionals in the project file. This requires manual editing of it, though.

If you’d like, you could create a separate branch on GitHub and push your current work there so @nathanletwory and/or I can take a quick look?

You mean @nathanletwory :slight_smile:

Oops. Got your attention, at least :wink:

Hi guys,

Thanks for looking into it. I’m realizing that this may be a Visual Studio issue, rather than a Rhino issue. Let me just share with you what my solution setup is. Here is my solution explorer, with all current projects linked. Note that there are two solutions for Pachyderm for Rhino (Pachyderm_Acoustic (the v6 version), and Pachyderm_Acoustic-RV5 (the v5 version)):


They both reference the same files, except that the v6 version has two unique files with minor code changes for compatibility. Now, here are the settings for the v5 version pertaining to output location:

and here are the settings for the v6 version pertaining to output location:

I agree that it looks awfully like the v6 version was overwritten by the v5 version… I don’t understand why that would be the case under these settings. Do you?

kind regards,


@idid and @fraguada have a similar setup for Speckle and Iris. Do you guys have any idea what could be going wrong here?

What changes did you have to make? Maybe we can just make some fixes in RhinoCommon so the Rhino 6 will just load the V5 version of your plug-in.

That would be wonderful! Let me do a diff and get back to you.


Here is what I know of:

  1. I have an object properties page. In the parent class for Rhino.UI.ObjectPropertiesPage, there is a virtual (I think) item called PageControl. In V5, it returns a ‘Control’ object. In v6, it returns ‘object’.

  2. In Rhino.UI.OptionsDialogPage, the same issue occurs. PageControl outputs ‘Control’ in V5, and ‘object’ in v6.


I beieve @JohnM was working on a fix for this. John has this been fixed in the current V6?