We are trying to figure out the best way to install a native rhino plugin that is part of a larger set of software tools. We would also like to support installations in managed environments like universities and domains with the ability to install for all users.
Should we be using YAK or is it recommended to manually install the plugin?
Is it advisable to manually modify the registry to install the plugin?
Is there documentation describing the best practices in this regard?
I have also noticed that when installing using a local package the metadata discovered in the manifest during package building is not used in the Package Manager dialog, all the fields except name and version are blank. Is this a known issue regarding locally installed yak packages? Yak does appear to confirm appropriate YML manifest data during the package building process.
I doubt we have any kind if installer “best practices” document.
The nice thing about the Package Manager and .yak packages is that it’s simple. It also works cross-platform (both Windows and macOS).
If you require something more complex, perhaps you want install in Program Files on Windows or ask the user some questions before installing, then you’ll need something more sophisticated. All vs current user would fall into this category.
On Windows, MSI installers are the standard. This kind of installer will need to modify the Windows Registry.
I’m not familiar with the installer technology used on macOS.
I would definitely go with Dale’s recommendation for at least a core component. The officially supported mechanism, aside from being quite clean and well thought out (Yak/Package Manager) is going to work much more reliably as Rhino is updated and if you do have a problem, repro steps for the McNeel Devs are going to be very easy.
If you have some other dependencies to install, I’d either invoke them from that core component installed by package manager or tell the user that they need to do so.
That way, if any aspect of your multi-app install is having a problem with some nonstandard client use case, you’ll be dealing with your own internal messages and fixing them instead of reporting an obscure Rhino error message that noone else is seeing.