Cross-Platform Rhino Plugin Development with .NET

[Shaoyi_Wang]

Hi Rhino Developers,

I’ve been reading through the forums and came across some useful insights about developing plugins for Rhino. However, I have some questions regarding creating cross-platform plugins that can run smoothly on both macOS and Windows.

From what I’ve gathered, it is recommended to ship plugins for .NET Framework 4.8 for compatibility with Rhino 7 and test the plugins in .NET 7 to ensure everything works as expected. Also, using .NET Core on Mac eliminates a lot of compatibility issues between the Mac and Windows versions of Rhino, making it easier to make plugins work on both platforms. More info here.

I am developing a cross-platform plugin intended to run on both macOS and Windows. Given that macOS does not support .NET Framework 4.8, I am concerned about potential compatibility issues. Specifically:

• If I ship my plugins targeting .NET Framework 4.8, will they encounter issues on macOS?
• How is .NET set up on the macOS side?
• What is the best approach to ensure my plugin runs smoothly on both macOS and Windows?

Many thanks!
Shaoyi Wang

[CallumSykes]

Good morning @Shaoyi_Wang,

@Shaoyi_Wang

it is recommended to ship plugins for .NET Framework 4.8 for compatibility with Rhino 7 and test the plugins in .NET 7 to ensure everything works as expected

Agreed, use the newer dotnet tooling if you can, it’s really nice.

@Shaoyi_Wang

If I ship my plugins targeting .NET Framework 4.8, will they encounter issues on macOS?

Net48 will not be used unless the plugin is for Rhino 7, then I believe mono will run net48.

@Shaoyi_Wang

How is .NET set up on the macOS side?

With Rhino 8, when you create a multi-targeted plugin (net48 & net7.0), windows allows for switching between both, however only net7.0 will be used on with mac.

@Shaoyi_Wang

What is the best approach to ensure my plugin runs smoothly on both macOS and Windows?

• Using a cross platform UI like Eto.Forms is a good shout
• Learning VS Code to run debug and run on Mac
• Test on both OS’s if possible
• Learn as many differences between Mac/Windows as you can, try to use built in behavior and do not hard code paths.
  e.g
  • Use Path.Combine instead of building paths yourself
  • Use Environment.SpecialFolder instead of hard coding → Environment.SpecialFolder Enum (System) | Microsoft Learn
  • Use preprocessor directives when you have no alternatives #if WINDOWS → Preprocessor directives - C# reference | Microsoft Learn

Hope that helps!

[mrhe (Mariusz Hermansdorfer)]

@CallumSykes

With Rhino 8, when you create a multi-targeted plugin (net48 & net7.0), windows allows for switching between both, however only net7.0 will be used on with mac.

How should a multi-targeted plugin be shipped, though? When building a Yak package I need to specify which assembly folder to build it from and hence ship the NET48 version. Is there a way to package both versions and have the runtime decide which one to load?

[CallumSykes]

@mrhe

Is there a way to package both versions and have the runtime decide which one to load?

Indeed there is.

Multi-target Plugin structure

If you put your manifest above the target frameworks and build in the same directory as the manifest, you’ll get a multi-target plugin

C:.
│   manifest.yml
├───net48
│       *.dll
│       MyPlugin.rhp
└───net7.0
        *.dll
        MyPlugin.rhp

Single-target Plugin structure

If you put the manifest inside one target framework, you’ll just target that version

C:.
└───net7.0
        *.dll
        MyPlugin.rhp
        manifest.yml

Hope that helps

[mrhe (Mariusz Hermansdorfer)]

Thanks! Learned something new today!

I guess that R7 on Windows will always choose the NET48 version. What about R8? Will it alternate between plugin versions depending on the runtime chosen by the user?

[CallumSykes]

This format of yak package will only work for Rhino8, but Rhino will pick the correct platform automatically. Rhino 7 packages require a single-target package as described at the lower end of the post.