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 http://wiki.mcneel.com/developer/rhinoinstallerengine/overview
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
have a common set of dependent assemblies that the plug-ins share
and be able to update a single plug-in or subset of plug-ins
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.
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.
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.
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).