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
I’m interested to hear your thoughts.
Lastly: the page http://wiki.mcneel.com/developer/rhinoinstallerengine/overview contains an intriguing link to a deleted page: “Configuring automatic updates for your plug-in”. Is there such a possibility? That would be awesome.