The latest Rhino WIP on Windows now runs in .NET 7 by default (vs. .NET Framework 4.8). This brings some performance improvements and aligns the .NET runtimes across Windows and Mac.
We will continue to support running in both .NET Framework 4.8 and .NET Core 7 runtimes on Windows. You can select which runtime to use via the SetDotNetRuntime command, or by passing /netfx or /netcore as an argument to Rhino.exe.
For Plug-In developers, note that some framework APIs are not available when running in .NET 7 or later, such as CodeDom, AppDomains, Reflection only loading of assemblies, and a few more. More details can be found about unavailable technologies, and breaking changes when running in the .NET Core runtime.
As long as your plugins do not use any of the unavailable APIs, it should continue to work as normal.
While we are early in this transition over to the new runtime, we’d love to hear your thoughts, feedback and bug reports here.
The current nuget packages should work for .NET 6 even though they don’t explicitly have a .NET 6 target. However, it is still recommended to target .NET 4.8 for your plugins so it can run in either runtime.
The console application sample for Rhino Inside will not run when TargetFramework is set to net6.0, but will work for net48.
Firstly just including the Rhino.Inside package will result in Cannot resolve symbol errors for the Rhino namespace. I can explicitly include the RhinoCommon package to get around this (version matching the RhinoCommon DLL in the WIP system directory) and set RhinoInside.Resolver.RhinoSystemDirectory to the correct place. However, I still get an error saying that the assembly RhinoCommon could not be found. I assume this because of a mismatch between runtimes, since switching the target framework to net48 fixes it.
Yes, you can target .NET Standard 2.0 however our nuget packages aren’t set up for that at this point. Either way, there’s still APIs in NET Standard 2.0 that don’t actually work when running in the .NET Core runtime.
We may consider doing that for performance reasons, but since we will support both runtimes the new .NET Core APIs would only be used when running in .NET Core.
I’m not surprised, we still have yet to get Rhino.Inside wired up for .NET 6.0. I created RH-70530 to look into that.
In Rhino mac wip (v8) system drawing is unavailable, and its replacement System.Drawing.Common is not linked. This makes everything involving colors (pointclouds, materials, etc.) not accessible right now. Haven’t tested it on windows yet, but the mac problem remains.
Edit: as written below - this happens in an C# component