Handling Multiple RHP Files for Multi-Targeted Plugin in Rhino 8

Rhino Developer
1

Hello everyone,

I’ve developed a multi-targeted plugin for Rhino 8 that builds for both .NET Framework and .NET 8. As a result, I now have two sets of DLLs and RHP files—one for each runtime.

The challenge I’m facing is this: if a user switches between .NET Framework and .NET 8, how can I prompt Rhino to load the appropriate RHP file based on the runtime in use? Is there a way to configure Rhino to recognize and load the correct version automatically, or would I need to implement custom logic to detect the runtime and adjust accordingly?

Any guidance on achieving this runtime-specific loading behavior would be greatly appreciated!

Thanks in advance for your help!

1 Like
2

Thats a great question. I decided to write a Rhino Launcher that starts rhino with the appropriate /netcore or /netfx switches so that I was in control for our users, and then loads our scheme/skin.

I’m curious to see how you solve this issue.

1 Like
3

@curtisw - is this something you can help with?

4

Put the rhp in an appropriately named folder related to the runtime, like net48, net7.0, etc.

1 Like
5

The latest Rhino Templates have all of this behaviour correctly set up so you can just get going with Debug on Win & Mac, net48 & net7.0, Visual Studio & VS Code.

Did you use these and are still having issues?

1 Like
6

Rhino plugins do not have a mechanism to use a folder structure to differentiate between .NET Framework 4.8 and .NET 8.0.

7

could you explain this further? Do you have access to the Rhino Templates?

Our Plugin quite successfully uses a folder structure to allow Rhino to load the .net 7 version.

8

Hi @CallumSykes @david.birch.uk,

I’d like to explain what I’m working on. I have a plugin built for both .NET Framework 4.8 and .NET 8.0. When I use Visual Studio or Rhino Plugin Templates, I get the same project structure for both versions.

My concern is how to package this plugin for distribution. Specifically, when I create an installer using WiX or Inno Setup, I need to ensure that Rhino can load the appropriate .rhp file based on the runtime. I’d like to know the best way to package this in the installer to handle this scenario.

9

are you distributing your plugin via the package manager?
Rhino - What is the Package Manager?

Even if you need your installer the best practice would be to make a Yak Package and have your installer install that.

Yak has ability to have 1 plugin package .yak contain a version for both .net 4.8 and .net 7 - this is done using folders as referred to above.

10

Thanks @david.birch.uk for the recommendation. However, I’m wondering if there’s another way to achieve this without using a package manager.

I was thinking about creating an external Python script that will be executed whenever Rhino starts. This script would decide which plugin to load. But, is it possible to configure Rhino to run this script automatically every time it starts?

I’m not sure if this approach will work or not.
and this script should be shipped in installer.

11

Why do you want to avoid using the package manager Yak?

Plugins distributed via yak can have any number of framework specific versions included in the same package. net48, net7.0, net7.0-windows, net7.0-macos etc etc. which means as long as you multitarget using the <TargetFrameworks> attribute in your .csproj, (included by default in current Rhino templates) you’ll build your 2+ framework versions and yak/rhino will handle loading the correct rhp from the correct framework folder. You do not have to write any custom behaviour, it is automatic.

So if you run rhino in net7.0 on windows, it will load net7.0, or net7.0-windows if it can find that. If you run net48 on windows, it will load net48, if you run net7.0 on mac it will load net7.0 or net7.0-macos if available.

Yak MultiTarget Guide here

I see you mentioning net8.0, do you have a preference for net8.0 over net7.0? If so, why? Rhino runs using net7.0 or net48, I’d opt for net7.0 if you can.

2 Likes
12

Yes, @CallumSykes , we need support for .NET 8.0.
Thank you for your help! I tested a sample plugin with .NET 7 and .NET Framework 4.8 using the Yak package, and it worked as expected.

I think need to wait until Yak Package Supports .NET8.

.

13

Why is this @Sushant_Joshi?

14

we are using one third-party library which is an essential part of our plugin which is built in .NET8

15

What’s the library? I’m surprised the base is net8.0 for a library, usually it’s an LTS like 7.0