So I have an LSystem Plugin that I put together and would like to make public soon(ish) as a free plugin, but I’ve really only been able to check it on two machines (worked fine). Having had an embarrassing experience once before though, I would really appreciate it if anyone had the time to try this out and run through a couple of the examples just to put my mind at ease. I’m mostly concerned about the local file structure: There is a section that loads a CLR DLL(s) dynamically and the path to the Help file is local.
FYI: It’s built using:
Version 5 SR4 (5.4.30524.11065, 5/24/2013)
TIA,
tom
(Examples and Docs included)
Download/Unpack/Load the RhinoLSystem.rhp/Command is “LSystem”
You might consider distributing your plug-in using the Rhino Installer Engine. This will handle installation and registration of your plug-in, so you don’t have to tell the user how to do that. It also handles distributing a 32- and 64-bit plug-in in the same package.
There’s nothing to install (hopefully - that was the intention), it’s keying of off:
Assembly.GetExecutingAssembly().CodeBase;
It should be finding everything local to the unpackaged zip. That’s what I want to make sure is working well.
I’ll read up on the installer though. Are there McNeel docs on 32 vs 64 bit? Looked, but could not find, or is that a CLR question? I was under the impression that if the code is pure CLR (no native dll calls), 32vs64 bit is handled by CLR internally? I’ll review that again. Yes, still learning the finer points of .net (java first), and I’ve had the luxury of working with all 64 bit machines so far and have never had to worry about these issues before…
Ran this plugin under both version of Rhino at home(32 & 64) and it worked fine (if that clarifies anything).
Thanks Brian,
So, the installer seems slick and I’m sold on the concept (thanks for providing it), but I ran into a little snag: The wiki page : Making your C# plug-in compatible with the Rhino Installer Engine Seems to just show the overloads for RMA.Rhino.MRhinoUtilityPlugIn. Is there a version for RhinoCommon Rhino.PlugIns.PlugIn?
Installer failed when I tried to use it (package not compatible)…
On another note, when I mentioned “dynamic” loading earlier, I guess what would be more accurate is “manual loading”: scan dir/load assembly/scan for public class/instantiate new/pack in dictionary …
I always get a little nervous trying non-standard stuff in other people’s environments…
