so, what is the Default value? is it netfx or netcore?
.NET core 7 is the current default in Rhino 8: Rhino - Moving to .NET 7
Rhino 7 is .NET Framework 4.8
Thank you clarifying,
It is going to be a windows vista moment for some plugins, especially for the older ones that are no longer in development, I guess time to move on.
By default, that could be. We are trying to improve the information when a plugin does not load so that some people might be able to switch the runtimes if needed.
Is it possible at runtime to test whether Rhino is running in framework or core?
ie some property in Rhino.Runtime or similar?
Sorry if I’ve overlooked it.
I believe Environment.Version would let you know
Thanks, hadn’t found that. Works great.
Oh… does that mean it only supports one runtime at a time?
So if the user wants to run a legacy 4.8 plugin and set their version of 8 to use the 4.8 runtime, then a 7.0 based plugin would stop working?
Dose .NET 8 come with Rhino 8 too? .NET 8 (LTS) is in RC1 now, seems like it will release next month.
No, we plan on sticking with .NET 7 for Rhino 8. We will explore the next version of .NET with Rhino 9.
Yes, only one runtime can be loaded into the Rhino process and you can’t “switch” runtimes while that process is loaded.
I’m not exactly sure what will happen in that situation. The plug-in loading code currently does not check compatibility when a plug-in is built for the same version of Rhino (we probably need to change that.) Rhino will probably attempt to load your plug-in and will throw an exception if it is using a function not available in .NET 4.8.
@stevebaer I would appreciate a comment regarding this earlier post:
I don’t have much to comment on here. Improved AVX support apparently exists in .NET 7 so developers could take advantage of this. Most of the core geometry, display, and rendering implementations in Rhino are written in C++.
Thank you, understood. Though I thought that grasshopper has a lot of .NET? Or is that only plugins there too?
Grasshopper as in the user interface and solving logic is entirely .NET. The geometric calculations that it uses for things like intersections and booleans are typically C++.
AFAIK I can load my 4.8 plugins in .NET 7 runtime.
Some of them, there are limitations. I have 5 plugins that refused to start.
Yes, 7.0 should be mostly backwards compatible, but there are edge cases which Microsoft discusses.
In fact, there are quite a few hits for setdotnetruntime here and at least one for which downgrading .NET seems to be the solution but I’m not sure how popular those plugins are:
Search results for ‘setdotnetruntime’ - McNeel Forum
My concern is that it would be a hard decision to try to deploy a plugin to Windows Rhino users which links .NET 7.0 since the situation seems to be uncertain as to whether that would introduce conflicts with legacy plugins.
In fact, I rewrote a small bit of code just now so I can compile against 4.8 because it’s worth more to me to know I won’t be forcing users to choose between plugins than it is to use 7.0.
Perhaps McNeel could set up an automated process to test every plugin at Food4Rhino and in the package manager so we’d know whether this will be a significant issue.
I find that our plug-ins when built for .NET 4.8 cannot be loaded when the user has set the .NET runtime to .NET Core. With some changes, I can also build the plug-ins for both .NET 4.8 and .NET 7 using multi-platform targeting and then it does work when the user has set .NET Core as runtime and they load the .NET 7 plug-ins.
This then gives an interesting dilemma: which plug-ins do I distribute to the users, and if I distribute one version and the user has set their runtime to an incompatible one, how do I handle that situation? It seems like giving the user the choice which runtime they use, puts problems on the developers to cater for the situation where the user needs to change their runtime to use your plug-in, thereby making it difficult/impossible to load other plug-ins that only work in the other runtime.
It would make more sense to me if Rhino 8 just took the plunge and only supported .NET Core, so that the developers can update their codebase and not have to worry if their plug-in is going to load into an incompatible runtime. But maybe I’m missing something?
Rhino.Inside is a factor here, Rhino.Inside.Revit for instance uses 4.8, they will be switching to 6.0 next year, which is not very helpful in this case.