I was trying to test my GH plugin for Rhino 8 and just switched the debug program from Rhino7 to Rhino8.
Then suddenly I got this:
Based on some basic search, it seems Rhino 8 has moved to NET Core for the multi-platform compatibility purposes.
Is there any guidance how this will affect the current GH plugins and how we should adapt to it?
Any McNeel staff here?
I am, but I don’t know the answer. I’ll make sure someone who does is aware of this question.
Hi @xliotx,
To start Visual Studio debugging in .NET Core, you need to either multi target your plugin so it compiles for both net48 and net7.0, or create a separate .NET 7 launcher project as outlined in our Moving to .NET 7 guide.
Hope this helps!
Curtis.
Hi @curtisw , thank you for the quick reply.
To support both Rhino 7 and Rhino 8, I guess a multi-target solution is the way to go?
I guess if I abandon net48, then my plugin won’t be available to Rhino 7, correct?
Yes you still need to target net48 for Rhino 7, and also for Rhino 8 when it is running in .NET Framework, which some users might need for things like Rhino.Inside Revit or other for plugins that are not yet compatible with .NET Core.
You don’t have to target net7.0 to support Rhino 8 as it can still load net48 assemblies, however going forward you would likely want to multi target your plugin.
Wait, if Rhino 8 loads net48 assemblies, then can I debug in Rhino 8 with net48?
Hey @xliotx,
Yes, Rhino 8 can run in either .NET Framework or .NET Core runtimes, you can tell it which runtime to use by passing either /netfx or /netcore as arguments. You can see a sample launchSettings.json file here how you might be able to debug Rhino 8 in either runtime, and Rhino 7 using the same project. launchSettings is configured using VS’s launch profiles dialog.
Hi I am supper confused right now, you are suggesting to use .NET 7.0, however I would like to point out that it is deprecated in accordance to microsoft. Would it also be possible to use .NET 8.0 for RHINO 8?
It’s practically impossible to develop faster than Microsoft does. Problem in this case is that NET 7 was not a LTS version, but NET 6 was , but probably not lasting long enough to use 6 instead by the time they started. Fortunately migrating to newer Core versions is not a big deal. Its mainly the transition from framework to core which is a bigger action. Its not always unproblematic to take the most recent versions, e.g. if you are lacking a compatible library. But yeah, maybe they should have shipped with 6 and than switched to 8 asap…
Hey @richard_schaffranek,
I second @TomTom’s comments and would like to add that upgrading the .NET version will likely cause havoc on all plugin developers and users as MS does remove features and have breaking changes in major versions now. That being said, we are working on getting Rhino 8 running on .NET 8 as an option, but it isn’t there currently.
As for using .NET 6, that was a no-go as it was not up to par regarding macOS support. It would also only give us 6 more months which would not have really helped much.
So it will run using .NET 4.8 framework or .NET 7.0 ?
Still think it was a bad choice using a short term support version but I guess I do not know all facts.
Rhino 8 Windows supports running in either .NET Framework 4.8 runtime or .NET 7.0 runtime.
Rhino 8 Mac currently only runs on .NET 7.0 runtime.
We are investigating adding .NET 8.0 support, and at least on Mac would require you to install the .NET runtime separately (.NET 7 runtime is included with Rhino 8 for Mac).
I hope this clears things up.
LTS is 3 years, non-LTS is 2 years. I would rather address this issue to Microsoft than McNeel. I personally think this is ridiculous for real world development. And 90% off all features introduced are garbage or not ready to be released. One good reason for NET7 was a significant performance boost on multiple level. So the 7 release was one of the more relevant ones.
Totaly agree on the microsoft part, but I guess unless rhino is relaying on .net nothing you can do about it.
STS is 18 month according to .net webpage. This means it is about half the time of the LTS. And here it gets relevant when e.g. implementing things like authenication via MSAL.
However as .net framework 4.8 is still supported as fare as I understood, this solves the problem.