I get systematic error messages when opening GH in V8.
240224_GH_Load_Ex.txt (2.1 KB)
Looks like it’s related to the Field lines.
1 Like
Hi Olivier -
I’m afraid that, if the names don’t tell you enough, you’ll have to use GrasshopperLoadOneByOne to find the offending plug-in.
-wim
2 Likes
Ha ! Didn’t know that one.
It’s kind of lame that this information is not given in the error log, don’t you think ?
Hi Olivier -
I suppose that could make my days better, yes → RH-80687 Grasshopper: Loading Errors: Provide tip
Apart from that, you are probably running into an issue with a plug-in that is targeting APIs in the .NET Framework 4.8 runtime, which are not available in the .NET Core 7 runtime that Rhino 8 runs under.
As a quick’n’dirty fix, you could use the SetDotNetRuntime command in Rhino to switch back to Framework. While that might get you up-and-running, it’s likely you’ll run into a new (version of a) plug-in at some point that is not supported when running under Framework…
-wim
It didn’t work. I loaded ALL the plugins one by one and finaly got the error message 
The very last one I loaded was GHpython.
Yes these components smell like python compiled objects. I’m not sure if the fault lies with them, or with the Python framework/runtime/compiler/parser/Ihavenoideawhatpythoncallsit. @eirannejad Do you know how to find out?
@osuire Is this the plugin you have installed? FlowLines - Addon for Grasshopper | Grasshopper Docs
I can replicate that with Rhino 8.5 on netcore. It runs fine on netfx:
@curtisw Grasshopper is loading IronPython generated component dynamically and here is the error:
Method not found: 'System.Reflection.Emit.AssemblyBuilder
System.AppDomain.DefineDynamicAssembly(System.Reflection.AssemblyName, System.Reflection.Emit.AssemblyBuilderAccess)'.
Is this something we can fix in netcore Rhino?
The plugin is a single assembly and does not carry anything else alongside it:
1 Like
Unfortunately not, that API does not exist in .NET Core, and is replaced with System.Reflection.Emit.AssemblyBuilder.DefineDynamicAssembly (which also exists in .NET 4.8).
It will need to be recompiled with that change to work in .NET Core.
Yes, I have the same issue; if I use the SetDotNetRuntime command, are there any disadvantages related to accuracy?
EXACTLY !
Thanks a bunch Ehsan !
1 Like
Hi -
No, there is nothing related to accuracy here. This is merely about the availability, or lack thereof, of lower level .NET functions that some plug-ins rely on. If they are not available, the plug-in will simply not work at all. It’s a binary yes-no situation, not a shades-of situation.
-wim
1 Like
I took a deeper look and the assembly actually doesn’t seem like being IronPython generated. It has internal resources that are being dynamically loaded at runtime which is causing the exception in dotnet core.
It would be great if you can reach out to their support email and see if they can compile this plugin for dotnet core.