Rhino WIP Feature: Get ready for .NET 7!

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.


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.


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#

@curtisw Do have any idea how this will impact compiling of ghpy components?

It shouldn’t, but it appears that it doesn’t currently work. I’ve created RH-73027 to fix that up.


Thank you!


we did have an issue tu run our plug in on Rhino 8 WIP, great we found some interim solution in your post.

I did two tests:

  1. standard run which I guess is /netcore

  2. /netfx and this time it worked

However to get it working on .netcore as well, any suggestions on which replacement in netcore for

object @object = Marshal.GetActiveObject("Document"); //HERE IS THE ISSUE

we could use in our code to get compliant with netcore version?
There is the version of our code that breaks in the original post

if something is not clear we are happy to explain further or provide more details…

Last question utill when are you planning to support .NET Framework? thsi will be by specific Rhino version or year?

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 :slight_smile:

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.

Hope this helps!

Very handy! Thanks :blush::blush::blush: