Problems with Memory load *.GHA assemblys in Coff byte arrays checked

Hi,

i have a problem when the Memory load *.GHA assemblys in Coff byte arrays checked in the the Grasshopper development settings. It makes me mistakes when it is checked, but works fine if not.

I have some XML serialisation and automatic building of input and output params going on. It seems what i can not have a class wich is serializing to xml when it is checked. but works fine otherwise.

Works fine without checked:

error when checked:

can someone tell me how to solve this Problem?

Replies to This Discussion

Permalink Reply by michael sprinzl on July 24, 2012 at 11:02am

works and checked does not:

Permalink Reply by Jon Mirtschin on July 24, 2012 at 12:42pm

Yep, I get the same issue with my plugins, I believe isolated to 64 bit windows but I'm not certain. I don't know what characteristic causes it, I believe if the assembly has an external reference it might not occur but again I'm not certain about this.

I used to set this option on behalf of users when my plugin first loaded, but this wasn't reversed when uninstalling so I'm back to constantly explaining to users they need to set this.

I'd also appreciate more knowledge or improvement with regard to this.

Permalink Reply by Virgil Johnson on July 24, 2012 at 5:17pm

It would seem to me that people would check their system memory, just thinking out loud. At least this brought about a solution for me.

Permalink Reply by Jon Mirtschin on July 25, 2012 at 4:58am

Can you clarify this a little? What do you mean check system memory?

Unticking COFF loading is the only solution I've found for this problem, and it happens with many many users.

Permalink Reply by michael sprinzl on July 25, 2012 at 5:24am

I have some kind of Proxy class in the namespace in which i use in the plugin. It seems what this causes the error,but i am not sure, maybe the Memory load *.GHA assemblys in Coff byte arrays does something like only getting the GH_component itself. Or it has some issues with static fields and classes and instancing. But i am only speculating. We need someone to clarify what GHA assemblys in Coff byte arrays do.

Permalink Reply by David Rutten on July 25, 2012 at 6:47am

I'm not ignoring you guys, but I don't have any answers either. COFF loading means that the assembly is not loaded from disk, but rather the file is first loaded into memory, then the assembly is loaded from memory. This disassociates the physical location of the assembly with the runtime instance of that assembly. COFF stands for common object file format incidentally.

There are two problems that are meant to be circumvented with this approach:

.NET assembly loading smarts.
Loading assemblies from locations deemed unsecure, such as over a network.

When you load an assemble from a dll file, .NET tends to be smart about it and it might instead give you a newer compatible version of that dll than the one you asked for.

Maybe it was a mistake to allow memory loading in the first place and maybe I'll remove the option when a I can think of a better solution. Perhaps it is causing more problems than it solves...

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by michael sprinzl on July 25, 2012 at 7:36am

Ok this sounds what , if you do a lot of generating assemblys during runtime and invoking or delegating to some functions you will run in lots of troubles.

Maybe it will even change these assembly in a unpredicted way.

I will have to dig depper into this problems. Oh my gosh. Thanks for your reply.

RSS