Comments (12)
Thank you for your help! I will continue communicating with Rhino developers!
from messagepack-csharp.
I assume the error is related to memory use. Hope someone and help me!
from messagepack-csharp.
I don't think we can help you with merely a "MessagePackSerializationException: Failed to serialize MyClass value." as the reported error message.
If you can include the full callstack and all inner exceptions, there's a better chance we can help.
from messagepack-csharp.
Thank you for your reply!
I can't find the full call stack. But I submitted an issue on the Rhino Forum: https://discourse.mcneel.com/t/get-an-error-when-using-c-script-component-to-get-nuget-package/182256/2
I will update this issue once I get any reply from there!
from messagepack-csharp.
@AArnott
Hi, Here is a new reply by the developer of Rhino software. He talks about the possible reason.
https://discourse.mcneel.com/t/get-an-error-when-using-c-script-component-to-get-nuget-package/182256/10?u=hani_leo
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 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)
from messagepack-csharp.
I wonder if the assembly name changes each time it is recompiled and loaded.
If the assembly name is unique each time, I would expect this to work. But if Rhino loads a new assembly with the same name each time, then you're in a decidedly unsupported scenario.
from messagepack-csharp.
Based on what the developer of Rhino said, I think the assemblies have the same name.
And I think the bug should be fixed by the developer of Rhino. 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.
I will continue communicating on the McNeel forum. Thank you for your response!
from messagepack-csharp.
the previously compiled assemblies are no longer useful and should not be stored in memory.
This may be a runtime limitation. .NET Framework doesn't support unloading assemblies, and I don't think mono does either. The newer ".NET" supports assembly unloading under certain conditions. I wonder which of these Rhino is based on.
Even if supported, unloading the old assembly requires that all references to that assembly be in the same AssemblyLoadContext and unloaded with it. This means MessagePack itself would also have to be loaded into the same ALC and unloaded with it, since MessagePack retains references to all types that it serializes for perf reasons.
from messagepack-csharp.
Rhino runs on .NET Framework on windows and mono on mac before version 8.
Now Rhino 8 on windows supports both .Net Framework 4.8 and .NET 7. I first tried run the MessagePack on .NET 7. But I get these errors, it can't find the attributes:
So I changed the runtime to .NET Framework, and it only works for the first time as we talked
from messagepack-csharp.
The attributes not being found isn't a runtime error -- that's an issue with build. Apparently MessagePack.Annotations isn't being referenced by the compiler.
from messagepack-csharp.
Yes, but this is weird. It can recognize all other package without this one.
from messagepack-csharp.
No denying it's weird... I'm just saying this isn't a MessagePack bug. Rhino is the odd one out here where all the issues are occurring, and MessagePack has proper dependencies between packages so that you shouldn't be getting attribute not found compiler errors, so all arrows point to Rhino being the problem and not something we can support. Sorry.
from messagepack-csharp.
Related Issues (20)
- [v3] Issue with AOT Platforms - DynamicAssembly HOT 2
- Document new diagnostics
- MsgPack011 issues when flagging nesting types
- Not supported primitive object resolver when using IL2CPP in unity3d HOT 1
- Formatter singletons should be accessible via `internal` static readonly fields
- AOT must accommodate `init` and `required` properties HOT 1
- `[CompositeResolverAttribute]` not yet that useful HOT 7
- Dictionary deserialize exception HOT 5
- MessagePack.Analyzers / MsgPack004 not working for records HOT 2
- Source generated resolver requires C# 9 HOT 3
- MessagePack.UnityClient is not available in releases HOT 1
- .NET Foundation adoption HOT 6
- Problem with deserialize string as enum in MessagePack HOT 5
- ///
- How to avoid boxing with struct serialization/deserialization HOT 4
- Flavor of `IMessagePackFormatter<T>` that passes large structs by reference HOT 10
- Scavenge old v3 ideas for new ones HOT 1
- add the option “If the type is nullable and it is not possible to parse the enum (it is not matched), then return null” HOT 2
- Generic MessagePackReader/Writer type arg for formatter HOT 4
- Is it possible to understand in which field the deserialization error occurred? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from messagepack-csharp.