Exporting tools defs as C#?

I have an armada for grasshopper definitions, id liek to internalise as c# plugin, is there a way to export a defintion represented as its code?

The simplest answer is probably: no.

There is no “translator” from visual programming to code (if i’m not wrong…).
Each gh components is either made by some simple rhinocommon call or dozens and dozens of specific code. We have no access to the second.

May I ask: why?
Why you want to “internalise as c# plugin” ?

Usually one choose to rewrite the definition/algorithm completely to c# for performance. That makes sense indeed.

But If you make it protect your code, it’s somehow wasted effort…


I generally write most of my helpers using GH as a basis to proof the tool, and then convert to c# with a winforms window for controls. usually because its awkward trying to train new staff how to find and load tools in GH format, and screen space is an issue here, so making small compact “topmost” windows works better, and having to learn how to do baking baking etc. Simpler to just use it in Rhino.

Longhanding it is not that tedious, was just hoping to improve my workflow.

You probably could write methods for the components you are interested in, then walk the component tree and realize them as code based on those methods or snippets.

I do this in GhShaderNodes. See GhShaderNodes/OutputNode.cs at c1e8b564a7b198689812cb5bc8ef1f323018c8cf · mcneel/GhShaderNodes · GitHub in the OutputNode where I look at the connected nodes to be able to generate a shader expressed in C# or XML.

1 Like

The paradigms are too dissimilar, especially if you adhere to best-practice programming standards, in which case, its better to just write a C# application from the ground up and use your scripts for reference and testing if the output of your C# app is the same.

1 Like

thanks, i save them as snippets in VS … simpler solution than i was aiming at.

Sorry, but what is the point (mis-)using snippets in VS? All you achieve with that is code duplication… If you have more than 2-3 lines of code which are repeating all over the place, then encapsulate that in a method and call that method.

because there are tonnes of methods and any one bit of code may only need 3-4 so i have found using snippets a fast way to insert them where needed

Don’t ge me wrong. If you think thats good for, than do that. I can only encourage you to not rely to much on snippets. They are meant to help with creating code patterns, not to inline helper functionality. Just imagine for some reason you need to slightly change the helper function, maybe inserting a log message or doing a certian check. In case you are using it in 30 places in 3 different assemblies, you will have a very hard time in modifying it. Apart from that, your line count will grow quickly for no good reason.

In that case, move the snippets to a VS solution. It could be as simple as a library of static methods if there is nothing resembling objects, otherwise use OOP.

In any case, you can compile your solution then distribute the assembly for consumption by your GH scripts. You would add the assembly reference like any other, then include your using directives and then you can make calls from your library. This also solves the problem @TomTom is getting at where you would otherwise be repeating yourself (DRY) and creating a maintenance nightmare. Compiling to an assembly means all your code is in one place and any updates can be propagated by redistributing the assembly file your graphs reference.