Installer best practice

Replies to This Discussion

Permalink Reply by Sridevi Koonath on May 9, 2014 at 2:46am

Hi Menno,

If you type 'GrashopperDeveloperSettings' into the Rhino command line, you will get the following window (screenshot). Here, you can view (or add new) folder paths where Grasshopper looks for .gha files to load.

Permalink Reply by David Rutten on May 9, 2014 at 2:48am

We recommend using RHI installers.

If that is not possible, then you need to inform Grasshopper about the location if your GHA files. It is possible GH will find these files if they are next to your RHP files, you'll have to test that.

If it can't find them, then either put the GHA files in the components folder (to be found at %appdata%\grasshopper\components I think) or put a *.ghlink file in the components folder. The latter is better if you'd rather keep your ghas and rhps in one place.

We no longer recommend messing about with the grasshopper settings xml files.

--
David Rutten
david@mcneel.com

Permalink Reply by Menno Deij - van Rijswijk on May 9, 2014 at 3:27am

Ok, that is very helpful. It seems that Grasshopper automatically finds the GHA install location (if I check valid folders using the GrassHopperDeveloperSettings command). If I understand correctly, this is because an RHP is loaded at start-up that resides in the same directory.

We can't use RHI installers I'm afraid, that has been tried in the past and does not meet our needs.

Permalink Reply by David Rutten on May 9, 2014 at 3:43am

Grasshopper looks in many locations for GHA files to load, including in all folders from which Rhino loads plugins. We did this specifically to make it easier for developers who want to distribute both RHP and GHA files simultaneously.

In the future we'll also try to make it so that Grasshopper can load components directly from .NET RHP files, which means you'll only need a single assembly that contains both Rhino commands and Grasshopper components.

[...] that has been tried in the past and does not meet our needs.

Do note that RHI is a work in progress. We'd love for all our 3rd party developers to use RHI, so if there's a feature you need, please do tell us. I can't guarantee that we'll add it asap, but at the very least it needs to be on the list.

--

David Rutten

david@mcneel.com

Permalink Reply by Menno Deij - van Rijswijk on May 9, 2014 at 6:20am

The problems we had/have with RHI are:

1. One RHP per RHI - users have to install multiple times - we currently have 13 plug-ins. This leads to a) version problems and b) angry users having to update 13 times, rather than once.

2. Related to 1: difficult to have shared state between RHP's in a shared DLL.

3. Installation of dependencies. In our case a FlexLM licensing service and MS redistributables.

It took me two days to go from zero knowledge of MSI's to a functional installer with WiX and we've never looked back.

Permalink Reply by David Rutten on May 9, 2014 at 6:40am

I see. I'll at least add the request to have more than one RHP per RHI file. We might not make it possible to run secondary installers from within an RHI installation, that sounds like a pretty high-end feature, but it's not up to me to decide what does and doesn't go into the rhiexec application, so maybe Brian will decide there's merit in it anyway...

I'm not trying to talk you out of WIX btw. If that's working for you then that's great. I'm just trying to figure out what new features would be best to add to RHI.

--

David Rutten

david@mcneel.com

Permalink Reply by Bill Manspeaker on June 13, 2014 at 3:48pm

  In looking through previous similar conversations I couldn't find a specific answer to how best to deploy Grasshopper to multiple machines.  In an academic environment you can have dozens of machines and hundreds of users sharing them and you want the environment to be consistent throughout.  RHI files seem more designed for simplifying deployments by individuals ("Just me") or for standalone deployments on a per machine basis but don't fit easily into an automated (e.g. Group Policy) environment.  As a general rule, you don't want to have to touch a machine for this kind of thing because that approach doesn't scale.  

  Right now we're building the files into a simple .msi with Advanced Installer and then creating a GPO that includes this in the software deployment section and, in the Windows Preferences section, the registry keys imported via Registry Wizard from a successful installation (this because Advanced Installer gets complicated when you need to insert keys in the 64-bit section of the registry where the Rhino plug-in keys live).  That unzipping an RHI file doesn't produce the registry keys makes a little more work in repackaging but that's possibly a feature as far as commercial developers are concerned.

  I'm curious now about WIX, to see whether that's a better tool for this purpose, but if there are ways to automate within the RHI framework I'd certainly be interested in hearing about them.  It's understandable to favor the developer side -- that's where the future is coming from -- but consider, as well, that if you can drive labor out of the deployment process that will also speed adoption.  

Permalink Reply by Menno Deij - van Rijswijk on June 15, 2014 at 3:18pm

WiX Will let you create an MSI and the correct registry keys (64 bits). It took me two days to get started without any knowledge on windows installers. We use a per-user installation method, but it can just as easily do per-machine installation and be used in grou policy based roll outs.

Permalink Reply by Bill Manspeaker on June 16, 2014 at 10:08am

  Another issue, if the practice is to create a new folder for each version release, is moving/coping the .gha additions (e.g. gHowl_r50.gha) from the old Components folder to the new.  Grasshopper doesn't use registry keys to recognize these pieces, so the Rhino update strategy of just moving all the Rhino plug-in keys from one section of the registry to another isn't applicable.  Because Grasshopper is straightforward in recognizing components if they're in the right place, pushing these components (ie. files) out by Group Policy simplifies making these changes -- updating the "Destination" for each component that was pushed out this way gets a copy in the new location.  

  Again, this isn't to say that RHI isn't the best way to go, all things considered; this is just to discuss how those who do larger scale deployments work with this approach.