I built a plugin using C# and the RhinoCommon API in VS, and I am having troubles understanding how to package the files to be able to be distributed via the Package Manager through a local server (not sure if that’ll impact anything or not).
The issue I am having is with building out the package for the Package Manager. The only files I have via the build from VS are the .rhp and .cs files (along with a few others misc. files). However, I don’t see a .dll file for me to include with the rhp and manifest.yaml file to use to build out the package/folder as mentioned in the package manager guide (example below).
Can anyone point me in the right direction or provide a solution?
I have reviewed the Package Manager & the Plug-In Builder Guide with no luck on helping me get past this roadblock. This is the first time I try to distribute a plugin made through package manager, so I am sure I am possibly just missing a bit of information.
You probably don’t need a DLL if everything you’re coding ends up in the plug-in, the RHP file.
On a side-note: the RHP file is in fact nothing more than a DLL with its extension changed, but that is beside the point: try to package just the RHP and any other files you do have, and see if it works.
I’m going to throw this additional point out because you mentioned a ‘local’ server for distribution.
The following took me quite a while to find because I was totally mistaken on the keywords: you can set additional paths for repositories Rhino should look in.
Dale F very patiently gave me some help along the way so thanks for that Dale!
I still think the help could use some updates in a few ways. This is written attempting to wear a QA hat of identifying a flow that seems to have some speedbumps, not me wearing a DEV hat and asking a specific question I don’t know the answer to.
You’ve published GREAT, and I do mean that, technical information. So please take the following comments in the spirit of constructive criticism to which I will cheerfully accept a ‘nope, not a problem for most people’ if I’m an outlier.
I think it’s hard to, as a newbie, work through what I think of as the following steps of development without a lot (hours) of searching around. This relates to Grasshopper in particular:
download tools (good)
code a plugin or two (good)
test in a debugging environment (good)
build and test locally (totally missing as an easy step to find if you don’t already have it bookmarked)
distribute an alpha version among other computers the dev owns, and then among a few testers (totally missing)
Post a beta version (help tells you how to push it to the repository, but lacks discussion of how this relates to listings in the package manager vs listings on the food4rhino website vs download links on the food4rhino website)
Do an actual release (coordinated between package manager, food4rhino, etc.)
Some of these have obvious solutions if you’ve been a user of Rhino and possibly a user of other plugins for a while. I’m pretty new to that (but not to the development side or the domain expertise side).
re:#4, yes, along the way I passed the “Custom Package Repositories” page, which gives the answer about how to get the package manager to also search a local directory, but the use case is actually installing a single plugin locally not managing a repository, so the web-crawling I was doing within the help files and the google searches were looking for entirely wrong keywords to find the answer. You can also find information that Rhino accepts drag and drop plugins, but I found this only in relation to an older (obsolescent?) package format even though it may still work now.
Rhino 7 now supports drag and drop install of .yak files for Rhino plugins. This is by far my most preferred plugin install method with my tiny user base.
This also includes UI updates if the .rhi file is included in the .yak. I do this by association of .yak files with WinZip so they open on double click and dropping the matching .rui file into the .yak folder.
Now that I think I know from another page or discussion that a rhp may simply be a renamed DLL, that may go a way towards explaining some things towards a local install if a vendor supplies their own installer rather than using the YAK packaging… but I’d still prefer to stay within the recommended distribution mechanisms.
Rhino plug-ins (rhp) and Grasshopper components (gha) files are renamed DLLs. These files are generated as part of the build process from Visual Studio. You can install them with the plug-in manager in Rhino and locally test/debug them.
Yak packages (yak) are renamed zip files that typically contain rhp and/or gha files. Yak packages are published for distribution.
@will we might want to add some instructions on techniques for locally testing your yak packages before publishing.
And perhaps a discussion of exactly what the install does. An example question: Does rhino register the component for you upon install? (use case: maybe the plugin also supports an interface for pulling data into Excel or another app so just the local visibility to Rhino isn’t a complete install. A separate install package isn’t a great option because then the end user could install two out-of-sync versions.)
See a few comments above for a suggestion of an additional help document describing the overall dev process from a private build up through publishing. The existing docs seem to provide good technical coverage of any given highly focused topic, but I can’t find an overall list of steps and how to achieve them from “I’ve got an idea” up through “end users are pulling from the package manager and from food4rhino” up through “licensing system connected to cloud zoo”.
I don’t think this would be an unreasonably large effort, as much of the technical info already exists. I think you’d just need a one or two page summary with pointers to the technical articles for each step, though that might also spawn some updates for current recommended practice.
is the package manager for distribution on the public or can it also be used for managing releases for a smaller group of Private / Corporate users? is there a method for access control and invitation?
