Plug-in deployment, RHI?

I’m looking for some best practices for plug-in development and deployment. Up to now, we have released internally a set of 10-15 plug-ins (mostly file import/export plug-ins) by putting them in a ZIP file and asking users to drag the RHP files onto Rhino. This works nicely if and only if the complete set gets renewed at each release and users remove the previous versions before starting with the new version.

In the future, we’d like to be able to release (updates of) a single plug-in or subset of plug-ins. To that end I have been exploring the possibility to use RHI files for deployment using the instructions on

This leads to each plug-in having its own RHI file, which is the granularity I was looking for. As an aside: it would be nice if also RHI files could be dropped on Rhino, similar to dropping RHP files on Rhino. Now, users will have to install each plug-in separately, instead of a single drag-n-drop of multiple RHI files on Rhino. But that is just a small usability improvement and not the main topic of this post.

In our case, most plug-ins have common dependent .NET assemblies, e.g. a library with geometry routines, or shared metadata. I have proceeded to put all the common assemblies in the folder of one “central” plug-in, which is loaded at start-up. All other plug-ins are loaded on demand and will use the common assemblies of the “central” plug-in if they need to. Surprisingly (to me at least) this works - a “sattelite” plug-in will find its dependent assemblies in the “common” plug-in’s folder. Can you see any disadvantages to this approach? The idea is that as each plug-in is released it is accompanied with the latest “common” plug-in, so that the plug-ins can always find the latest common .NET assemblies.

My guess is that this will work if the public API of the common .NET assemblies does not change in such a way as to break the dependency. This is nothing new, any component-oriented architecture will have this challenge.

@stevebaer and others: what are your experiences with maintaining a large-ish set of plug-ins with the wish to be able to

  1. have a common set of dependent assemblies that the plug-ins share
  2. and be able to update a single plug-in or subset of plug-ins

I’m interested to hear your thoughts.

Lastly: the page contains an intriguing link to a deleted page: “Configuring automatic updates for your plug-in”. Is there such a possibility? That would be awesome.

Hi Menno,
I have about 12 plugins and one library currently. I have been using a common library for one of my plugins as an experiment for a while, and it’s been working fine and I’m planning on changing my other plugins to do the same (they all use a couple of common types). The Plugins and Library all live in the same directory. This all sounds about the same as your setup, and personally I can’t report any problems - it’s been smooth sailing for me.

Have you considered log-in scripts for updating the plugins? I’ve seen this done with AutoCAD for in-house templates, utilities, etc, and it worked well. If rhino has had the plugin installed once already, you should be able to update all your plugins and libraries through the login script.


I’m going to reply, just haven’t had the time to think this through thoroughly.

Hi @TomC

Your situation resembles the situation I am in now: multiple plug-ins and their support assemblies are kept in a single directory. I am considering a different setup with one directory per plug-in, which is required by the Rhino plug-in Installer Engine which uses .rhi files. So far, this seems to work if all support assemblies are in the directory of a “central” plug-in that gets loaded on start-up.

Thanks for your suggestion re login scripts, this sounds interesting and I will see if this meets our needs for updates.

The scope of our update system changed after the initial docs for RHI were written. We intend to support plug in updating via RHI and the existing McNeel Update system, but don’t have that working yet.

Cool, that would be a very nice feature indeed.


I’ve read your post requesting best practices and am curious if you have any conclusions to share?

Thanks for posting the original question!

I have moved away from the Rhino Installer Engine, because we have about 10 plug-ins or so, that use a number of shared DLL’s. This would lead to the user having to install each plug-in separately, which was experienced as a hassle.

Instead, I have created a Windows MSI installer using WiX, which deploys all plug-ins and support DLL’s in one action. By making sure that it does not need administrator priviliges, the users can install updates by themselves.

Going from no experience with WiX and MSI creation to a working installer took me about two days, and I haven’t look back since.

1 Like


I’m starting to understand why this makes sense. I will take a look at WiX. Thanks for your help!


A quick question - are you using the Wix method to install toolbars as well as plugins?

I’ve posted my most recent installation questions [ here ] and would appreciate any insights you might have.

Yes, we use WiX for both plug-ins and RUI files. As long as the files are in the same directory and have the same name (except the extension RHP/RUI) the RUI is loaded automatically.
You should, however, ensure that the menu bars are saved in “open” state in the RUI file; otherwise the RUI file is loaded but you see nothing. This can be configured from the Toolbars Layout dialog (Tools -> toolbars layout).