Can not run plugin under Rhino8 OSX

Rhino Developer
, , , ,
1

Hello,

My problem is in the title, I can not make our plugin to run under Rhino8 OSX.

This is a RhinoCommon plugin and runs on Rhino 6/7 (net48) both win and osx version. It runs on Rhino 8 (net70) windows version, but it doesn’t run the net70 version under Rhino 8 OSX.
Debugger doesn’t reach the entry point so I am still just guessing what is wrong.
Probably something is missing, but I am not sure what.

Plugin builds fine, but I can see these error messages, for example:
warning CA1416: This call site is reachable on all platforms. ‘Bitmap.GetHicon()’ is only supported on: ‘windows’ 6.1 and later.

So maybe this is the problem? In case yes, what is the correct solution? Even RhinoCommon uses SystemDrawing.Bitmap so I can not simply replace it with something else.

Any idea?

Thank you,
Márton

2

@curtisw - can you assist?

3

Hey @marton.parlagh,

Do you have an example of what you’re trying to do? It is normal to get those warnings (for now), and net7.0 plugins should be working in Rhino 8.

It would also help to know what the actual error you’re running into is, what you’re trying to use for debugging, etc.

Cheers,
Curtis.

4

Hello @curtisw ,

It is hard to tell what is the actual error - but as I have understood from you answer it is surly not because of the warnings about “only supported on win…” right?

Here I build with Visual Studio Mac 17.6.7, it uses Microsoft .NET Core Debugger (vsdbg)

It can be an important factor, that I am on a M1 macbook and running Rhino in Rossetta mode (the plugin doesn’t support native M1)

As I wrote before, the Rhino7 version runs fine under Rhino7

The only two differences between building for Rhino 7 and Rhino 8 is:
For Rhino 7
<TargetFramework>net48</TargetFramework>

For Rhino 8
<TargetFramework>net70</TargetFramework>
and for Rhino 8 I add this too:

<ItemGroup>
	<PackageReference Include="System.Drawing.Common" Version="8.0.0" />
</ItemGroup>

Building goes fine, but if I run the Rhino8 version I see that Rhino found some part of the plugin, but otherwise it doesn’t run it. (And debugger doesn’t want to attach itself to the code:( )

Actually I don’t understand why Rhino finds the plugin at all, because if I check the Visual Studio Application output window it doesn’t show any plugin related line, so it seems it avoids the plugin.
But still I can see our custom plugin commands in Rhino, the menu of the plugin, and the plugin name among the render engines.
(But if I run any of our commands Rhino does nothing. If I select our render engine, it doesn’t show our render engine ui, I guess menu is from the rui file so that is ok…)

As I wrote before the Rhino 7 plugin runs fine under Rhino 7. But if I run it under Rhino 8 it also doesn’t work well at all.
Compared to the version built for Rhino 8, the net48 (Rhino 7) version shows a bit more life. I can see our plugin settings inside Rhino settings. And in this case if I change the render engine to our plugin the ui is changing too. Also it can add our custom plugin attributes to Rhino objects.
But it still doesn’t show the custom material and the custom environment type of the plugin. In case the render engine is set to our plugin, I can see inside the material/environment editor the “current renderer doesn’t support materials/environments” message.
And our custom plugin commands are still not doing anything. (This very same net48 build runs fine under Rhino 7…)

Any idea?

(I can send our plugin installer…)

Márton

5

Sorry if it’s obvious, but if I saw some “this call will be made and won’t work on that platform” type compiler warnings and the app does in fact not run on that platform then I’d comment out the offending API calls (making any other tweaks as necessary to keep things basically running) and see what happened.

An icon load sounds like something that might be done on startup.

6

It is a good point and this is what I normally do too.

But in this case these warnings are because of System.Drawing.Bitmap and System.Drawing.Icon objects.
And these are required for different RhinoCommon functions.

For example:
public override bool VirtualIcon(System.Drawing.Size size, out System.Drawing.Bitmap bitmap)

or:
Rhino.UI.Panels.RegisterPanel

So…

7

I’d still think that if removing them gets your plugin to load and maybe do something like a console.write(“Hello World”) then you’ve gained some useful information. If that works, then build up from nothing (maybe even an empty plugin) and see if a particular call you need isn’t supported and ping the forum with that.

Since the compiler warning wasn’t enough to trigger “Oh, I’ve seen that; here’s the fix” from anyone then the more focused you can make the question the easier it’ll be for McNeel to help you, or another dev to take your simplified example and say “Oh, I’ve seen that pattern before.”

See my recent example, DrawMeshWires Working, DrawSubDWires Not Working? - Rhino Developer - McNeel Forum

If I’d said “My plugin doesn’t seem to be drawing SubD’s” I probably wouldn’t have gotten much.

Pulling the code out of the plugin to make the simplest 3DM and script example I could including an almost identical call which works for a different primitive to prove that I was setting up the display pipeline correctly got me on the to-fix list in a few hours.

8

@Nathan_Bossett you are right.

Márton

9

Ohh, the problem was in front of my nose but I was blind to see it.

I run Rhino in Rossetta mode, but it still runs the arm version of NET core:
This is a line from the debugger application output:

…/Contents/Frameworks/RhCore.framework/Versions/A/Resources/dotnet/arm64/shared/Microsoft.NETCore.App/7.0.0

The plugin connects to some x64 only c++ libraries (no arm version), and Rhino tries to run them as arm binaries - so it fails.

@curtisw Could you check it please? Is it something solvable on your side?

Thank you!
Márton

10

Hey @marton.parlagh,

When debugging, it would depend on the debugger set up on which version is run. If you’re using Visual Studio for Mac, then that would explain why it is loading Arm64 as it doesn’t support debugging in Rosetta mode.

I would suggest moving over to Visual Studio Code (since VS for Mac is being retired anyway), which does allow you to set it up to debug in rosetta mode, an example launch.json to do so would be something like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Rhinoceros (Mac .NET 7 ARM64)",
            "type": "coreclr",
            "request": "launch",
            "program": "/Applications/Rhino 8.app/Contents/MacOS/Rhinoceros",
            "targetArchitecture": "arm64",
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "externalConsole": false,
        },
        {
            "name": "Launch Rhinoceros (Mac .NET 7 Intel/Rosetta)",
            "type": "coreclr",
            "request": "launch",
            "program": "/Applications/Rhino 8.app/Contents/MacOS/Rhinoceros",
            "targetArchitecture": "x86_64",
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "externalConsole": false,
        },
    ]
}

Hope this helps.

2 Likes
11

Ok, so my observation was not correct, it is not Rhino but the debugger forces the arm mode.

Thank you!

Márton

12

How can I load Rhino plugins in Rhino 8 for Mac? Drag and drop loading like on Windows does not work. Is there a hidden command to locate a plugin and load it?

1 Like
13

Hello. Perhaps this is the place?

As explained above, when Rhino for Mac launches, it searches the contents of the:

~/Library/Application Support/McNeel/Rhinoceros/MacPlugIns/

folder scanning the sub-folders looking for .rhp files. When it finds such “file” (which are actually packages), Rhino for Mac attempts to load the assembly with the same name contained within this package. If you are maintaining your own installer, simply writing your plugin to this folder should be sufficient.

Version-Specific Installations

If you are maintaing your own installer, in Rhino 8 for Mac onward*, it is possible to register version-specific installations. To do this, your installer will need to create a MacPlugIns folder within the version folder that resides in:

~/Library/Application Support/McNeel/Rhinoceros/

For example, to register a plugin that only Rhino 8 will load, your installer should write to:

~/Library/Application Support/McNeel/Rhinoceros/8.0/MacPlugIns/YourPluginName

14

Many thanks for this hint!
I was asking the question because I am developing and debugging a plugin on Mac, i.e. I want the plugin to be loaded from the build directory. I made it work now by creating a “fake” package in Library/Application Support/McNeel/Rhinoceros/packages/8.0, and use a symbolic link to my build output folder. That works well, but I still wonder what’s the official way to solve this.

1 Like
15

I’m pretty sure I don’t do this, or at least I’m not aware of it, but my current plugins seem to be registered, I have no idea how to make new ones do it though. I’d love to understand it a bit better

– cs

16

Perhaps, since the plist still contains information about where you got the plugin from, why don’t you delete the plist and try to start Rhino again?

Or, if you are using Rhino8, I think you can use the [Reset] command to restore the environment to the very first state.

https://wiki.mcneel.com/rhino/mac/resetprefs

1 Like
17

Sorry, I haven’t tried it, so I don’t know if it works, but it looks like there is a sample for VSCode that passes debugging.

"passDebugOptionsViaEnvironmentVariable": true,.
            "env": {
                // optional: register your plugin(s) to load
                "RHINO_PLUGIN_PATH": "${workspaceFolder}/Path/To/MyPlugin.rhp", "rhp": { // optional: register your plugin(s) to load
                "GRASSHOPPER_PLUGINS": "${workspaceFolder}/Path/To/MyGHPlugin.gha", "GRASSHOPPER_PLUGINS": "${workspaceFolder}/Path/To/MyPlugin.gha"
            }
1 Like
18

This works very nicely

1 Like
19

This has been updated a smidge, new docs below :slight_smile:

1 Like
20

Thank you for your very helpful documentation!
I created a new project, debugged, etc. and everything worked fine.

2 Likes