Hi @stevebaer,
do you already know whether or not you are going to run Rhino 8 on .NET 5?
Also, I am curious to know why are you using C:\Program Files\Rhino 8 WIP\System\runtimes\win-x64\native\WebView2Loader.dll?
Thanks.
Hi @stevebaer,
do you already know whether or not you are going to run Rhino 8 on .NET 5?
Also, I am curious to know why are you using C:\Program Files\Rhino 8 WIP\System\runtimes\win-x64\native\WebView2Loader.dll?
Thanks.
We will not be targeting .NET 5, but are investigating .NET 6
We are actively working on switching to .NET 6 for the Mac version of Rhino 8. We haven’t made a final decision on if this will be done for Windows yet and I’m hoping we can learn a bit more from our Mac experiments before we make any sort of switch on Windows. If we do support .NET 6 on Windows, we would probably also allow for a mode where .NET 4.8 is still used so Rhino can run inside of existing environments like Revit that may still be using .NET 4.8.
All that said, I would recommend plugin devs continue to target .NET 4.8.
WebView2 is installed with Rhino 8 and Eto uses this to provide a modern embedded browser on Windows. We are using WebView 2 for our new code editor which is based on. Monaco Editor
I have tried to run .NET 5 Grasshopper plug-in inside the current Rhino with some success, thanks to geometry is stored with RhinoCore/openNURBS. And the shim layer, shipped from Core 3, helps with passing managed types between two frameworks. They can run side by side.
That approach will only get you so far; I promise We really need to have a single framework that our assemblies are working with.
Oh you have tried that. Shouldn’t have wasted one afternoon doing that…
So I suppose the only solution would be multi-targeting?
I would recommend continuing to target .NET 4.8 for all plug-in and GH component development. Due to runtime compatibility, most of these compiled assemblies can be loaded into .NET 6 when and if we get there.