Get an error when using C# script component to get nuget package

Get an error when using C# script component to get nuget package (Template script)

Changed nothing, but no error for now…

1 Like

New problem:

Same code works fine in VisualStudio.

I believe it’s a bug of Rhino

Here is the file. (11.4 KB)

Running the definition in Rhino 8.8 RC and not seeing any errors.

The first component is pinging which does not even work if I run ping on the terminal. Remember for security, web endpoints might not respond to pings.

@eirannejad Thank you for your reply!

I’m using Rhino8.7.

As for the first ping test component: it works well on my computer.

As for the MessagePack related c# components:
Yeah, it runs well after I change the framework from .NET 7 to .NET Framework.

But there is still a problem. It only runs well for the first time, and then will keep reporting an error.
Only delete it can copy the code to a new c# script component can solve it.

I submitted an issue related to this on the MessagePack-C# Github repository: MessagePack only works fine for the first time. · Issue #1821 · MessagePack-CSharp/MessagePack-CSharp (
A screenrecording video is in this link above. I put it here agin:
I only commented one line, and then it keeps reporting error, even uncomment the same line won’t repair it.

I can’t reply to the author replyed to the github issue, because I can’t see the full call stack of the error.

Another problem appears :cry::

1. Error running script (ExecuteException): Method not found: 'System.String MessagePack.MessagePackSerializer.ConvertToJson(System.ReadOnlyMemory`1<Byte>, MessagePack.MessagePackSerializerOptions, System.Threading.CancellationToken)'.

It found this method yesterday, so why can’t it today?


I will try to explain this the best way I can, but first let me ask what are you trying to do in this script? By looking at the using System.Net. statements and the fact that it is creating JSON data I am assuming you want to send some data to a web api.

If that is the case, dotnet core provides a very handle System.Text.Json api. Here is an example:

using System;
using System.Linq;
using System.Collections;
using System.Collections.Generic;
using System.Text.Json;
using System.Text.Json.Serialization;

using Rhino;
using Rhino.Geometry;

public class Script_Instance : GH_ScriptInstance
    private void RunScript(object x, object y, ref object a)
        var batman = new SuperHero
            Age = 85,
            FirstName = "Bruce",
            LastName = "Wayne",

        string jsonData = JsonSerializer.Serialize(batman);

        var superhero = JsonSerializer.Deserialize<SuperHero>(jsonData);

public class SuperHero
    public int Age { get; set; }

    public string FirstName { get; set; }

    public string LastName { get; set; }


The C# Script component continously re-compiles your code every time you make a change. This means that there is an unnamed assembly in memory for every time you have changed the C# script. Each one of these assemblies end up containing a Script_Instance and MyClass implementation.

The MessagePack library you are using in the example above has a dynamic type resolver that based on my quick inspection seem to get confused when the script is changed. It runs fine the first time, but on the second attempt (after editing the script and compiling a new assembly by the component backend), it gets confused on how to resolve and serialize the type MyClass. As I mentioned above this type is now in a completely different assembly but has the same name.

I did not dig deeper into the code behind this library. Here is the the inner exception stack. Seems like there is an exception in the static constructor of the FormatterCache<T> type.

   at MessagePack.Resolvers.DynamicObjectResolver.GetFormatter[T]()
   at MessagePack.Resolvers.StandardResolver.FormatterCache`1..cctor()
--- End of stack trace from previous location ---
   at MessagePack.FormatterResolverExtensions.Throw(TypeInitializationException ex)
   at MessagePack.MessagePackSerializer.Serialize[T](MessagePackWriter& writer, T value, MessagePackSerializerOptions options)
   at MessagePack.MessagePackSerializer.Serialize[T](T value, MessagePackSerializerOptions options, CancellationToken cancellationToken)
   at Script_Instance.RunScript(Object x, Object y, Object& a) in rhinocode:///grasshopper/1/bc8f6a2e-38f3-4a28-ab06-7ff244bd8d2a/93d481be-7cf3-445f-af65-5520b5cf9f99:line 63
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)

You can point the developer to this message.


Rhino 8.8 Release Candidate is out and is slightly better at handling error lines in C# scripts :smiley:

Let me know how else I can help.

Thank you Ehsan!

What I’m currently doing is building an app on my HoloLens. The goal is to establish a peer-to-peer connection between HoloLens and Rhino/GH on my laptop. So that it can facilitate the process of the data transfer such as real-time head position, hand joints positions, and geometry information between these two devices.

I will follow your advice and try using the System.Text.Json api!

1 Like

Hi Ehsan, the developer of MessagePack-CSharp just replyed to this link:

Based on my current understanding, the bug should be fixed on the Rhino side rather than on the MessagePack side.

Since the C# script component recompiles each time the code is changed, the previously compiled assemblies are no longer useful and should not be stored in memory.

Could you share your opinion on this?

I fixed a bug related to the versioning of the dynamically compiled script assemblies and it seems to be working now. The fix will be in then next Rhino 8.8 RC build

RH-82075 Zero versioning of C# script dynamic assemblies causes issues

Thank you! That’s nice!

Here is another issue about nuget package referencing in .NET 7 runtime:

You could have a look on this issue on GitHub. We have some updates.
I really hope MessagePack could run successfully on Grasshopper.

RH-82075 is fixed in Rhino 8 Service Release 8 Release Candidate 4.

Hi Dan,
RH-82075 refers to the bug in .NET Framework?

I found another issue when run Rhino in .NET 7.

@Hani_Leo What is the other issue?

Here it is:

In this GitHub issue I just mentioned.

@Hani_Leo Great. I put a fix for this in latest 8.8 RC. Would you mind testing that?