Rhino Script Compiler for Rhino5, second Beta

Do you close your file after creating it?
If not then that could explain why you can’t read it it

@stevebaer, i just re-post 3 wishes here in the hope that the compiler can get some love in the future:

  1. Please support / allow to include python modules
  2. Please allow to include custom files in the compiled rhi (rui, chm, pdf files etc)
  3. Please allow to control the compiled plugin version number

thank you,


hi Clement,

Maybe i misunderstand, but currently it is possible. RHI is just renamed ZIP, so if you open it using zip software, you can add any files you want. Or compile to rhp, and zip together with your files, then rename to rhi.

EDIT: unless you ask for ability to pick files from compiler project level for better automation. That indeed would be handy!


Hi @Jarek, that is the reason. Currently it makes a lot of work to update a plugin made of multiple scripts and other files without making errors. The most useful addition would be modules. I have a plugin with a dozen scripts which could all access a single module. To compile the scripts, i need to copy the module code into every script. If i update the module i need to repeat this again, so i have 2 versions of all scripts, the ones which are compilable (having the module code) and the ones which are not compileable and access the module in a regular way.

If i just could recompile the project and all files (scripts, chm, pdf…) referenced in my rhc project would be taken automatically, it would save a lot of time.



yeah, definitely! I also would find that very useful to automate packaging scripted plugins.

RH-35623 and RH-57990 are fixed in the latest WIP

Ok, that’s jumping the gun a little bit :slight_smile: We’re going to try and get an updated version of the Script Compiler in next week’s WIP.

1 Like

Since I’m working on this project… how would you like to be able to work with things like chm and pdf files from your scripts? I understand the need for python library support (which is still something I’m hoping to add). I’m trying to figure out how these other embedded resources would be used.

Hi @stevebaer, thanks for looking into this again after such a long time.

I’ll try to explain first how i use aditional files in my scripts which i regularily compile into a single plugin file (rhi) using the RhinoScriptCompiler:

Pdf, Chm is used to provide helpfiles and documentation which are rolled out at every new PlugIn Release and get installed by the rhi installer. I always provide a toolbar file as well which contains buttons to open the help or documentation files. Here is the first hurdle to take, how to get the proper path to use as button command to open the helpfile ? I know how to get a relative path from a plugin of course, but if you have installed the rhi file multiple times, the version numbering is kind of random and makes it hard to figure out the proper pdf or chm file path.

Note that i regularily have to update all files which i include in the rhi file. So the second hurdle is, if a user just installs an updated rhi without manually removing the existing install, the installer creates a folder with a new version number and puts all files there. When Rhino 6 is then opened, the outdated toolbar is loaded, the updated one is ignored.

Another issue is that users are still able to choose the “All Users” and “Only me” option during the rhi installation. I had cases where the user just tried out both ways ending with multiple installs of the same PlugIn. You can repeat that simply by installing the same plugin multiple times, a new version numbered folder is created. This makes it very hard to find out where the helpfiles are located in order to open them. The company i work for has even provided PowerShell scripts to first remove old installs in order to prevent all of this, but some users never read help docs and therefore end with multiple PlugIn Installations, for multiple Rhino Versions.

As we all know, there have been major changes between V5 and V6 in regards to dimensions. Please, really Please provide a way so we can control for which Rhino version a compiled PlugIn (rhi and rhp) is allowed to be installed. It makes no sense to install my PlugIn in V6 and V7 if it deals with dimensions but was written for V5. Atm, all i (can) do is to check (in every compiled script) that the correct Rhino version is present. I would prefer to prevent the install before so i can get rid of all this code, which of course would be nice to put in a module or library.

:wink: I would kiss you then, but only if you’re not infectious. This is defenitely one of the most demanded things for me, even higher than having dockable WinForms.

One question about this statement. Does this mean that the compiler is no longer a seperate exe file and it only is included with the WIP ?


1 Like

Thanks, this helps me a lot in understanding your process. I have added the ability to set version numbers to the compiler so you may be able to use that to help make decision. I’ll need to think about how to make this easy to access from a script.

I’m focusing on V6 and V7 as targets with this version of the script compiler. I can tweak things so you can still create a V5 plug-in, but at the moment the plug-ins created with the new compiler are only for V6+. I have also removed the rhi compile option in favor of always just generating an rhp and a yak distribution. I can add the rhi logic back if we find a strong need. For now you can manually create rhi files if that is your preferred method of distributing your plug-ins. @will has been thinking about ways to make it easy to host your own private yak server for maintaining internal yak packages which are a much better solution for keeping everyone up to date with the correct version. By yak, I mean the TestPackageManager command in V6 and the PackageManager command in V7.

This new compiler targets V6, so V5 won’t be able to load these plug-ins. Is that a problem that I need to work on?

I can totally understand. The current situation doesn’t really help people maintain good coding habits by having reusable functions. I think I can get this to work by unpacking modules to a temp directory, adding this temp directory to the top of the search paths and then running the script.

No, the script compiler is an independent exe that includes an embedded V6 RhinoCommon that plug-ins are compiled against. We can include this in V6 as well or ship this as an independent exe.

Getting this in the WIP is more of a convenience for me so I can keep updating the project and let everyone stay in sync.

Sounds great. If i can rely on the version number i set in the compiler (which is later the folder name which is created) that is all i need to have to build a relative path. This would also ensure that users can just overwrite an installation and all files provided with the installer.

Please make sure to keep the Compiler Option to choose the RhinoCommon.dll. I have a larger client where it often takes a long time to roll out a new SR, so i have stored all RhinoCommon.dlls for all Versions and SRs. This way i can work with the current Rhino SR and still compile with backward compatibility.

OK, i thought you would offer a way to include extra files in the rhi installer. Currently the workflow is to create rhi, rename to zip, include extra files, rename to rhi, then publish. Have to admit, I never used yak. I’ll have to look into it and discuss with others. Double clicking the rhi was easy enough for most of the users.

No, if i have to make changes to those older V5 PlugIns i can still use the current compiler. I favor V6+ for all new PlugIns.

I have done something similar to make larger projects using modules “compilable” by automating a copy of the module code into every script. The difficulty was that the imports really need to be on top in order to find out which code (or individual function of a module) to include. The purpose of this was to have the module code encrypted along the regular script code. Just extracting the raw module code into a temp folder is problematic. I guess that purpose #1 of compiling a script into a PlugIn is to obscure the code and protect intellectual property.

thank you again for this great support, stay healthy !

All plug-ins are compiled against the V6 SR0 version of RhinoCommon. Do you need to compile against other versions?

I still need to think about this a bit. My current plan is to embed everything into the rhp and provide some way for you to access and unpack these resources if you need to.

Temporarily creating and quickly deleting these files is probably the best I can do for now. I know this isn’t ideal for IP concerns, but it seems better than nothing

You too! My wife and I are doing well… apart from me driving her nuts :slight_smile:

1 Like

Oh, and @Jarek the new compiler will support transparent commands

1 Like

Are you 100% sure ? I thought the compiler uses the RhinoCommon.dll of the current Rhino installation (in case of V6). I had one case where the client was not able to use the compiled plugin. He was at SR12 and i was at SR21, so i needed to recompile using the RhinoCommon.dll for SR12. I mean the compiler Option in the PlugIn Settings > SDK.

Sounds interesting too. It would then require a re-compile if only a helpfile or toolbar has been changed. I guess there is no way around if those files can be included from within the compiler. But it makes testing with included (embedded) files harder. If a file can be physically copied to the PlugIn installation directory, it can be accessed by a (non compiled) script for testing. At least this is the way i test everything before i compile or update a PlugIn.

Risky if i can restore them. I was thinking like TestLoadEncryptedScript so they cannot be viewed as raw scripts. (This is for rvb)


Yep; the new compiler has an embedded version of RhinoCommon from V6 SR0 that is used for the compilation process. This means you don’t even need Rhino installed on the same computer that you run the compiler on. If you need to set a minimal Rhino version for your plug-in to work because of some feature we have added of some bug we have fixed, we’ll need to add some feature to the plug-in to inform the user that they need a newer version of Rhino.

Ok, I’m still trying to figure out the best way to deal with extra files. Still pondering…

rvb is a different beast. I can probably get in-memory python modules to eventually work instead of writing to a temp directory, but it won’t happen right away as it is “hard” and I’ve got a billion other projects to complete. I haven’t even gotten the library support working yet… :slight_smile:

I don’t know how interesting this is to you, but one of the reasons for the script compiler reboot is to support grasshopper definitions as commands. At least my monotone voice can put you to sleep in just 10 minutes.


But does a compiled script then still work if i use eg. a RhinoCommon function which was added after eg. SR20 ?

Maybe i should explain what i initially had in mind. I thought i could “connect” some files (pdf, chm, rui) using the compiler dialog which are then automatically put into the resulting rhi file. Those references whould be stored (with their paths) in the rhc file. When i re-compile, eg. if the scripts, help files or toolbars have been changed, i could skip the rename to zip part and everything is pulled automatically from the paths…

That would be best, especially to avoid problems when debugging (with variable function scope vs. module scope). It would also prevent problems when modules need refresh during runtime.

It is very interesting and i look forward to use GH defs in my scripts too. Btw. I can only see a large blank space after your text above yet. Did you fall asleep ?


Rhino in general doesn’t have the capabilities to figure this out. I think we’ll need to add some minimum Rhino version setting to the compiler. The plug-in can the just say “hey, get up to date with at least x.x version” when loading and then refuse to run.

1 Like

+1 for setting a minimum and maximum Rhino version within the compiler. Btw. The GH features shown in the video looks very promising yet :slight_smile:


Hi Steve, maybe it would be enough to add a seperate section in the rhc xml structure like this:

    <file source="E:\SomeFolder\HelpDoc.pdf" destination="\documentation\"/>
    <file source="E:\SomeFolder\Toolbar.rui" destination = "\"/>

and provide something in the compiler interface to choose those files. If the rhc remembers the source path (and maybe allows to define a relative destination path when those files are installed) this would be enough to skip the rhi to zip renaming.

btw. have you thought about the ability to include a licensing related feature like password protection for the installer file ? I guess @Jarek would benefit from this too.


Including the files with the distribution isn’t hard. I need to figure out a way to let your script know where the directory your plug-in is executing to so you can access these files from the scripts.

The rhc project file now favors relative paths instead of absolute paths. You should be able to place all of your scripts and resources in the same directory as the rhc project file.

I can add functionality to the plug-in to run custom code of yours when the plug-in first loads and have the plug-in refuse to load if your script determines the plug-in shouldn’t load. Would that be enough for your needs?