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.
Hm, these particular differences could be because in .NET 6 there are a few fixes and changes to WPF. In particular it might have different font measurement logic would be my guess 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.
Shouldnât it be safer to target NET Standard 2.0?
Are you planning on using in Rhino 8 new .NET Core APIs not available in .NET Framework, and if so, what will happen with Rhino 8 and Rhino.Inside.Revit?
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
Hey @curtisw, looks like some progress was made on this, any chance it could be pushed over the finish line? No particular rush but I canât run my unit tests on mac which would be handy
Hey @csykes, getting Rhino.Inside running on Mac is on the radar but not high priority at the moment. That particular YT is to get Rhino.Inside published for running with Rhino 8 on Windows.
Unfortunately, Rhino.Inside for Mac v8 wonât likely be done until sometime after Rhino 8 is released, and there may be some hurdles that we have to figure out to get it fully functional.
