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.
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.
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.
Clearly, migrating to .Net5 for Rhino 7 would be a bad, if not impossible, option right now. Sooner or later it will have to happen, though. My hope is that, by then, the Rhino/GH team will be overcome with an unfathomable urge to redesign the UI using .Net Maui, if you get my meaning…
You are assuming .NET maui is functional by then. Currently it doesn’t even compile and link according the discussion pages of the project. We already use the cross-platform library Eto
I was not aware Maui was that delayed, although it’s understood that .Net 5 is being released this November, but many important features will only see the light of day with LTS .Net 6 one year after. I hope that’s not the case with C#9 though, because it’s looking really good!
This thread is about dealing with differences between .NET framework and .NET core that we are dealing with as we update Rhino to use a newer version of .NET. I was pointing out one of the differences in memory mapped files.
Regarding WIP and WPF I have some issues around RhinoWindows.Controls.WpfHost I think System.Drawing.Common is dead in net7 and where are still dependencies to Forms I guess…Is where an alternative approach? I see what where is a loot of fiddle diddle effort going on in this topic.
I have the issue that RhinoWindows could not be found after upgrading to .NET 7 for Rhino 8: error CS0246: The type or namespace name 'RhinoWindows' could not be found
For some reason, the .NET upgrade assistant removed the reference to RhinoWindows in my project. Adding it back worked fine.
Hi Steve,
sorry I forgot. Too much work on my desk. I think System.Drawing and Forms is not in the net 5.0 above anymore. Or better said maintained to current stage. I think as i remember - the “old school” bitmap makes big pain in conjunction with wpf. Where is a new way of handling it, but it starts getting more and more difficult. Same goes with System.Text.Json. Where is a libary for 4.8 net but I think it is always a littlebit “different” to the net 5.0 above stuff. So what I think Microsoft will not keep everything up to date. lets put i this way. It works somehow.
