Intermittent compatibility issues

Arthur · June 29, 2018, 2:06pm

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!

Arthur

nathanletwory · June 29, 2018, 3:42pm

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

will · June 29, 2018, 4:13pm

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?

Arthur · June 29, 2018, 4:19pm

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…)

Arthur

will · June 29, 2018, 4:34pm

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

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!

nathanletwory · June 29, 2018, 4:36pm

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.

Arthur · June 29, 2018, 5:30pm

Will,

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!

Arthur

will · July 2, 2018, 9:10am

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

Arthur · July 2, 2018, 11:00am

The latest. I think that is 6, right?

Arthur

will · July 2, 2018, 3:00pm

@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=2.0.0.2, Culture=neutral, PublicKeyToken=null

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

nathanletwory · July 2, 2018, 3:05pm

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.

will · July 2, 2018, 3:12pm

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?

nathanletwory · July 2, 2018, 3:15pm

You mean @nathanletwory

will · July 2, 2018, 3:21pm

Oops. Got your attention, at least

Arthur · July 2, 2018, 5:30pm

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,

Arthur

will · July 2, 2018, 5:58pm

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

stevebaer · July 2, 2018, 6:13pm

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.

Arthur · July 2, 2018, 6:30pm

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

Arthur

Arthur · July 2, 2018, 6:44pm

Here is what I know of:

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’.
In Rhino.UI.OptionsDialogPage, the same issue occurs. PageControl outputs ‘Control’ in V5, and ‘object’ in v6.

Arthur

stevebaer · July 2, 2018, 7:13pm

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