Rhino WIP Feature: Get ready for .NET 6!

The latest Rhino WIP on Windows now runs in .NET 6 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 6 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 6 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.

12 Likes

Thanks Curtis for putting this out!

I have noticed Eto controls behave a bit differently in .NET 6:

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.

Are .NET6 compatible nuget packages available?

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?

1 Like

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.

1 Like

Great, thanks Curtis.

I got linked here by @nathanletwory because of this problem i have: Rhino Wip missing lots of Assemblies - System.Drawing, Threading etc

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

As I replied this works just fine for point clouds, including access to System.Drawing.Color (tested on Mac)

Sorry - didn’t specify the language: it does not work in C#