Switch to .NET 5 for Rhino v7

Hi Team,
I’ve been searching around the forum to see if there were plans to switch to [.NET 5] (What's new in .NET 5 | Microsoft Learn) which is due to land in November 2020. I was disappointed to find this recent thread where @dale commented that you are sticking with the full framework for v7.

I understand there is probably quite a bit of work to make the switch, but I think it would be a massive missed opportunity to stick with full framework. As a Rhino plugin developer I’d like to outline some of the key motivations for holding off Rhino 7 release so that you can adopt NET 5:

  • Performance: Access to latest high-performance stuff, for people writing computationally demanding plugins. e.g. Span for fast memory access or SIMD double-precision vector calcs. Here is a list for perf tweaks which landed in NET core 3, and I believe the trend will continue for NET 5.
  • Tooling: code analysis + dotnet build which I think is way tidier than the old MsBuild tools
  • Cross-platform: no more messing about with Mono
  • New C# APIs For example: native JSON support or HTTP/2
  • Latest language features. c# 8 is available to full framework projects, but not everything.
    Some great stuff coming down the road with c# 9 which and would be a shame not to have access to, if MS decide that they are only going to support NET 5.
  • Code Sharing Share code with non-rhino plugins without having to do dual build or conditional compilation. e.g. cross-platform net core WPF app or ASP Net core web project
  • Consistency MS will be recommending that all new projects are .NET 5, and that is what people new to the language will be using for thier hello world demos. I also think it will quickly become frustrating when people google a solution to a problem only to find that that the code or tooling is not supported in the Rhino plugin ecosystem.

I know it’s a big ask, but please do give it some thought. Rhino 7 has been in the works for several years now, and it would be a shame to be shackled to full framework until 2024 while we wait for rhino v8. .NET is making huge leaps forward since ditching legacy full framework support, and I think Rhino needs to keep up.




I fully suppport this - it would be really nice to use the “single framework to rule them all” .NET 5 where the .NET Core and .NET Framework are unified going forward.

1 Like

I would also support the switch to .NET 5 for Rhino 7 though I understand its a big ask.
4 Years before switching with v8 is a long time.

Looks like this boat may have just sailed. A quote from the Rhino dev mailing list this afternoon…

The Rhino 7 SDKs and developer tools are ready. That means no more breaking changes

Hey @tom_makin!

Does the recent switch to .NET Framework 4.8 not solve the issue of sharing code between Rhino and modern core/net5 projects?

We also have a version of rhino3dm (formerly Rhino3dmIO) that targets .NET Standard 2.0 for projects outside of Rhino.

I know it isn’t the “one .NET to rule them all”, but hopefully it’s a start!

1 Like

Hi @will,

In my experience, net 4.8 does not add much on the code-sharing score. It doesn’t get a mention in this table for example, as things haven’t moved on since net 4.6.1 when net standard 2.0 support was introduced

I’ve found net standard 2.0 is a viable option for basic stuff, but as soon as you stray into net standard 2.1 territory then you have to start poly-filling and hacking around. e.g. JSON support, code analysis attributes, file IO helpers, and all the new high-performance stuff.

I read the exact same thing - you’re probably right that this is not going to fly.

We are not switching to .NET 5 for Rhino 7.

This would hold up release of Rhino 7 by many months if not over a year as well as potentially break existing plug-in / grasshopper components and many existing Rhino.Inside scenarios. That’s just the Windows side; changes on the Mac side will also require a lot of work to switch from Mono to .NET 5.

.NET 5 is not scheduled to be released until November 2020. It is something we are interested in eventually supporting. I have been working on .NET 5 support, but still haven’t gotten to the point where we could load Rhino in a headless console environment without some changes required due to binary incompatibilities.


OK, but then it would be gold for some of us if Rhino8 would go solely for a switch to .NET5, and go directly from there to further enhancements (Rhino9). In this way the “~1 year delay” wouldn’t be a delay at all, it would only take it’s time, while life goes on. :slight_smile:

// Rolf

It’s… complicated. We need to figure out how to support existing and future Rhino.Inside scenarios.


I’m happy it’s your problem and not mine… :wink:

// Rolf

In this scenario what would be the motivation for customers to spend money on a new version of Rhino with the same capabilities as the previous version?

R7 - Motivation as usual.
R8 - “Pre-release of R9” for those who needs it (doesn’t concern most users at all, but it doesn’t delay them either as they wait for R9).
R9 - Motivation as usual.

So, R8 would be a “dot on the line” towards R9, wich most users shouldn’t bother about while R( would represent a “pre-release of value” for those who need it.

// Rolf

@stevebaer Thanks for the definitive answer on this. I’d be interested to hear more about some of the pain points you have had with NET 5 so far. My full framework to net core migrations have been pretty painless to date, but I haven’t been doing much native interop so can’t comment on that score.

As suggested by @RIL I think it would be great to see a dev friendly Rhino 8 follow soonish afterwards. I think “Pre-release of R9” model sounds sensible, or perhaps licenses for 7 could also be valid for 8 to address the point made by @davidcockey?

None for the near future. We do upgrade core technologies from version to version without really announcing them as a “reason to upgrade”.

My tests so far have been to try and figure out how to use .NET Core instead of .NET Framework when the top level process has already loaded and initialized .NET Core. Basically just trying to make a Rhino.Inside console app that makes a mesh from a brep when the console app is written against .NET Core. I am able to have Rhino detect a different runtime being used and use that instead to initializing .NET framework. This still doesn’t work because

  • MemoryMappedFile.CreateFromFile has an overload that we use that doesn’t exists in .NET Core
  • System.Security.Cryptography.RSAParameters is not serializable in .NET Core while it is serializable in .NET Framework

Both of these issues can be worked around, but these are the first two that I have encountered while just trying to get a hello world console application put together with no user interface.

1 Like

Thanks for sharing that @stevebaer. I think it’s really helpful to get an insight into your battles behind the scenes. This does sound like a particularly tricky case though, so hopefully things will get easier when you shift attention to other parts of the codebase.

Why not make the NET 5 transition a Rhino 7.5 release (or .1, .2, … .9 depending on timescale) and make it available under the R7 licence so only motivation needed is to respond to the “new version is available” message. Then the next feature update can be R8 as it would otherwise be.

Hi @jeremy5,

Rhino is used in too many critical processes for us to make this kind of change mid release.

These kinds of upheavals are best left to major releases, and with a WIP process that gives developers time to digest the changes, and us time to debug them.

– Dale


But the release number is only nomenclature, it doesn’t dictate how much effort you put in. I believe the proposal was to change the platform without significant change to functionality - i.e. a refactoring exercise. From a user perspective it wouldn’t seem like a major release (even if it proved to be a significant headache for other stakeholders).

Hi @jeremy5,
This would be a major change from a third party development perspective, and would cause havoc if users bumped to the next minor version automatically without all the plugins also being updated at the same time. Unless Rhino was somehow able to support full framework in parallel with NET 5 I think it would have to wait for a major release cycle.