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
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.
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.
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.
@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.
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.
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).
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.