Hi all,
Is there any update on this issue?
Or nothing has changed since, and a DLL is still a preferred way to pass custom class objects?
Thanks,
Tim
Hi all,
Is there any update on this issue?
Or nothing has changed since, and a DLL is still a preferred way to pass custom class objects?
Thanks,
Tim
nothing has changed
got it, thanks andrew !
One thing I never quite understood was why you could dynamically reference an external assembly in GhPython by doing
import clr
clr.AddReferenceByName("myLibrary.dll")
import myLibrary
myLibrary.DoStuff()
Whereas the equivalent action seems to be artificially restricted in the C# scripting component because the using
declarations at the top are all grayed out.
âManage Assembliesâ is a really clumsy option because it somehow only uses absolute file paths, meaning every new user who opens the definition has to manually relink their c# assemblies one at a time.
Am I missing some other way of doing things?
Also, one can pass anything one might like to between GHPython components.
If your class acts as a data container, you can avoid using a dll in several ways, for example by passing the data in a tuple or anonymous method, for example:
public class SomeClass{
public object data0;
public object data1;
public SomeClass(object D0, object D1){
data0 = D0; data1 = D1;
}
public SomeClass(object A){
ImportAnonymous(A);
}
public object ExportAnonymous(){
return new {Data0 = data0, Data1 = data1};
}
public void ImportAnonymous(object A){
try{
Type t = A.GetType();
data0 = t.GetProperty("Data0").GetValue(A, null);
data1 = t.GetProperty("Data1").GetValue(A, null);
}catch(Exception e){
RhinoApp.WriteLine(e.ToString());
}
}
}
Emitter:
SomeClass sm = new SomeClass(12, "Hi");
A = sm.ExportAnonymous(); //A is object
Receiver:
SomeClass sm = new SomeClass(x); //x is object
Print(sm.data0 + ", " + sm.data1); //12, Hi
Well, that is the runtime-language equivalent of referencing a .dll for compilation, so itâs really one step before adding the âusingâ that is in C#. Python import
is the same as C# using
here.
Thanks for the reply! I understand that aspect of it, but I was asking why you canât edit the âusing
â section of the C# scripting component in the same manner, without using the âManaged Assembliesâ GUI.
For example, I canât define a custom Kangaroo2 goal in C# script and send the definition to someone else without them having to go through the manual step of finding where their KangarooSolver.dll is located and relinking it.
Is this a specific limitation of compiled vs. interpreted languages? I imagine that the KangarooSolver
assembly reference (for instance) would already be bound and loaded in the grasshopper environment , so one should be able to include it via a using
directive without specifying an absolute file path