Plug: Code Generation to Visual Studio from GH (C#) ScriptComponents

OK, shameless plug;

Over time I’ve been extending my little C# to VS code generator (from Grasshopper’ C# ScriptComponent) to VS code, and I thought I might share it with this generous community which has shared so much with me.

The published version is compiled but I have a GH ScriptComponent version in which I do all my actual enhancements (due to the quick response in GH) and then I sync the exported source with the VS version using a DIFF tool.

(the original code generator I converted to VS by connecting a copy of “itself” as a source component… but today the component itself contains templates and code layouts which - if “reflecting upon itself” - gets a bit complex to preserve through the code generation process).

I’m considering making the component open source (that is, the C# script component version contains the “original” source) but only after some heavy code refactoring so the sources can be shared without too much shame.

Limitations: Some bits are still missing, like the code template for DataTree inputs (for the DA.SetDataTree(int, value); syntax) with proper generic type casts etc, so if anyone has a well working syntax for this I’d be quick to add it.

I also had a bit of a problem to preserve skip sequences in text, like “\n” and “\t” etc. It works for some strings but not for all of them, depending on if they’re plain text feed via an Input or part of the source code itself (Anyway, for this reason I simply replace any such skip chars with a forward slash instead, so a little bit of “manual post-processing” in VS may be required for this).

There’s a video clip* on Vimeo demonstrating a simple use case.

Attached is also a better code generation example (gh definition) which converts my special XorSliders ScriptComponent into VS code (requires the updated CS2VS plugin version (Edit: replaced after bugfix):

ScriptCodegenerator_CS2VS_forum_demo_1.7.7.4.ghx (261.1 KB)

// Rolf

* The clip was recorded running the Codegen component in debug mode from VS, so please disregard the display of error catching caught in the VS IDE, the compiled component will of course turn red instead).


Thanks, @RIL, this seems interesting! I’ll surely check it out.

really a nice hit , (quick compiler) in grasshopper

@piac, he initial version had a template bug, now fixed in R1.7.7.4 (new version uploaded on food4rhino), also the uploaded example file in the previous post above is updated. Sorry for the bug.


I use to have the auto-generated file open in VS so I can benefit from VS compiler hints, and messages from plugins for VS, for example Rosalynator suggesting coding conventions. Then I can fix it in the code in script component immediately and then in realtime see the messages disappear in VS when fixed;

// Rolf

That’s what I’m really in need these days , boring state of load , unload process . but as far as I need to check the component operation time every time I can’t use script component

i’ma install it right now

Be aware of that some code conventions doesn’t work in Gh ScriptComponents (due to C# and .NET versions). So I simply disable those conventions from Rosalynator which doesn’t work in both VS and GH C# ScriptComponent.

In this way I can sync the code both ways, from Script to VS, and from VS to ScriptComponent.


I should have mentioned it, but since the code layout is restricted in the ScriptComponents, and I strive to generate code in such a way that a diff tool would identify similar code sections in a “clean way”, for this reason I place code blocks in a certian order in the VS version. I may post a screenshot illustrating this.

However, some parts of the code could still have a different disposition (so far I moved the template only for such code which I absolutely had to move in order to silence the diff tool (reduce differences to a “clean” comparison).

The main code areas to consider, are:

Main method:

  • ScriptComponent - Code begins inside the main method “RunScript”.
  • Visual Studio - Lots of boiler plate code before the SolveInstance method.

Class members:

  • ScriptComponent - Has to be declared after the main method
  • Visual Studio - Usually class members are declare before the main method(s)

"Additional code" (script)

  • ScriptComponent - Placed after the main method
  • Visual Studio - Can be placed anywhere, before or after the main SolveInstance method.

All in all, there are two code blocks from the script component which is copied into VS “as is” (except for some replacements to allow component syntax also in VS…), which means that there are only three places (before, middle and after the two code blocks) where to inject extra autogenerated convenience code if one want to be able to do have a “clean DIFF” and be able to merge code both ways between VS and Script Components.

Clean diffs
All this layout stuff is good to know if the code layout seems “backward” in some places (some code is placed at the bottom of the file which you normally would place at the top in VS, and so on). But clean DIFFs and simple two way merging of modifications is worth the “strange” layout, in my opinion.

Customized code layout
But code layout can be modified using external code templates attached to the respective inputs (when I publish the format to be used).

// Rolf

Some screenshots about using a DIFF tool on the resulting code:

To begin, the first similar code lines is the code in the main method of the ScriptComponent

Fig.1. Similar code (white clean DIFFs) starting from VS row 138 / GH row 70

This diff (Fig.1) shows that the code generator added some code in the VS version before the ScriptSource code was inserted into the SolveInstance method “as is”. It also added a lot of additional code before that, but only such VS code which is not useful for merging back to the ScriptComponent (if modifying the code in VS and sync is desired).

Thus, showing a diff of the code from the top of the files is entirely meaningless. Everything of interest starts on line 138/70.

Fig.2. Next diff screenshot shows the end of the “main method” area (marked red). Some code original was inserted but commented out by Codegen (since it lacks access to type info for the outputs), and below the end “}”, and the code generator also inserts some new code before the “Custom additional code” (see the left VS side)

And finally (Fig.3.) some code, like properties versions of the Input Params etc, is inserted also after the < Custom Additional code >.

Fig.3. VS code continues where the script is ending with some extra added convenience features, like autogenerated properties etc.

In short: The aim has been to generate as much “white” (clean) DIFFs as possible making it simpler to maintain two-way code sync between VS and the ScriptComponent.

// Rolf