@DanielPiker
How can I access Manage Assembly for the new RhinoCode-c# Editor ?
mac os x 13.5.1 (22G90)
Version 8 WIP (8.0.23241.14306, 2023-08-29)
I wanted to adapt some of the nice examples
using the new Script-Editor RhinoCode in Grasshopper, Mac.
The old Editor had Manage Assembly on the right-mouse-menu.
How can I access Manage Assembly for the new Editor ?
Errormessage
The type or namespace name 'KPlankton' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'KangarooSolver' could not be found (are you missing a using directive or an assembly reference?)
for older versions / the old editor this is solved:
THANKS
EDIT:
here is copy of an easy example … new editor not working… missing assembly CustomGoal_01_WIPV8.gh (18.6 KB)
This involves loading the DLL in the context.
in C#/Rhino there is only one context.
So what is loaded by Grasshopper is accessible by Rhino.
What is loaded by Rhino can be accessed by Grasshopper.
What is loaded by any means is accessible everywhere (Rhino/Grasshopper).
(I have not tested the following for you, this is under user expert control).
But a workaround could be:
Use Assembly.LoadFrom (You can call it multiple times, just one DLL and those dependencies will be loaded)
or you can use a Grasshopper script node to load the DLL (the old editor with Manage Assembly).
If this doesn’t work, it’s because the new editor doesn’t build the C# code with the same dependencies as Rhino (Like the old editor).
So this would be a feature request to make.
Do you support the #load directive?
And is it possible to load a DLL compiled with RhinoCode into another script?
Let me explain, for the moment I use my own editing system.
The implementation is different from RhinoCode but the objective is the same.
I often have standalone scripts that I would like to link to other scripts.
I use Roslyn Script Compilation which embeds the code in a state machine and makes it difficult to access.
This is problematic, because the only way to include script A in another is to use the #load directive.
This involves having to recompile all scripts that depend on script A.
I haven’t tried RhinoCode in a long time, I will, but in my experience it would be very convenient if the DLLs generated by RhinoCode could be linked with the #r directive.
#r "/Applications/RhinoWIP.app/Contents/Frameworks/RhCore.framework/Versions/A/Resources/ManagedPlugIns/GrasshopperPlugin.rhp/Components/KangarooSolver.dll"
using System;
using System.Collections.Generic;
using Rhino;
using Rhino.DocObjects;
using Rhino.Collections;
using Rhino.Geometry;
using Grasshopper;
using Grasshopper.Kernel;
using Grasshopper.Kernel.Data;
using Grasshopper.Kernel.Types;
// **************
using KPlankton;
using KangarooSolver;
using KangarooSolver.Goals;
// **************
I have an additional question regarding this topic. With the earlier version of the code editor, I got IntelliSense for the added DLL. Is there any way I’m able to have this in the new editor?
I have an additional question about this way of referencing the dll. As I understand it, such references cannot be set inside the program using variables? So when opening the file using another instance of Rhino or another computer, is there a way to avoid manually going into every custom goal and changing the filepath? I am making a definition that other people will have to use regularly, and this would be very cumbersome.
I am not sure what do you mean by “goal”. If you want to reference and load a dll in a script that runs on multiple machines, that dll needs to be in an accessible shared location, or be on NuGet
By goal I mean a kangaroo goal, which uses the KangarooSolver.dll. Previously, the script component asked you to manually select a new file path if the file seemed missing. This makes sense in Grasshopper with so many commonly accessible plugins that are locally saved. Even with an accessible shared location, dropbox, for example can have different file paths to the same file for different users.
This means that now, if you have scripts referencing dlls, you either have to upload them to nuget, which could have some legal and security issues(?) and require an internet connection, set up a commonly accessible file with the same file path for every user, or in many cases go into every script component and change the file path manually when using the definition. Including instructing people with no knowledge or interest of doing so.
This would be much easier if grasshopper had a folder where you could put dlls, a bit like the component folder, that enables referencing them in scripts without manually setting the whole path.