Best practice for updating new versions of released components

Grasshopper Developer
1

Hi all,

I thought this question might have been asked thousands of times but looking at the forum I couldn’t find an exact answer. I’ll try to make this as comprehensive as possible so hopefully can become a resource for anyone having the same issue in the future.

The problem: we’re developing custom code to solve specific parts of different GH scripts we have. what we do at the moment is using the C# component. The problem happens later when we have a newer version of that code, which means we have to open all previous GH files that have used it and manually update them.

The possible solutions: looking into ways of solving this there seem to be a few pathways:

1- Make a GH package and publish it publicly on the package server. This was suggested because of the internal Package Manager, and the functionality it has to recognise new versions:

image

The problem, however, is that it doesn’t give a notification to the user. So the user can continue on using the old component, unless they update the plugin manually.

2- Create a separate component that checks the version of used components, compare it against the newest version and somehow flag it to the user in the ‘dashboard’ of the GH file. This is somehow similar to the way Ladybug checks the version of their components using the LB Versioner component.

image
image711×362 26.8 KB

This is great but I’m guessing it works because LB components are python based. So they can be overwritten while Grasshopper/Rhino are running(?). Under the hood this component runs the pip install in the command line or downloads the specific version of files from Github. Our components are going to be .Net based so I’m guessing we can’t have a component that downloads the latest files and overwrites the old ones, as the old components get loaded and files get locked when Grasshopper is first running. Could a .Net based plugin use this approach in any way?

3- Make the components as a separate GH file and using Hops, point to a location on server where the GH files are. If there will ever be an update we theoretically only need to replace that GH file on the server. As long as the inputs and outputs are the same things should work. But, a couple of issues with this solution. Firstly we need one additional license allocated to that Rhino instance that’s running on server which are currently a rare thing in our office. Secondly, some of the components we’re developing need to be running on the local machine because they need to interact with the Rhino instance that the user has. eg: if we want to use a C# component to take a screenshot of the viewport, we can’t use Hops for that. Is this assumption correct?

4- Somehow automate updating the custom components. Eg, creating a script that automatically opens GH files, one by one, checks the version of a specific component, if it’s old replace it with the new version. Save and close the GH file. I’m not sure if this is possible at all but if so, pointers on how to do this are much appreciated.

Is there any other possible way to tackle this problem?
If not what would be the best way out of the suggested ways above? We need a solution that:

  • Doesn’t require additional Rhino license.
  • Gives a notification to the user about the old components when they open the GH file.
  • Can update the .Net based components, ideally by triggering that action from a “Versioner” component.
  • Can interact with the running instance of Rhino.

Thanks in advance.

2

You can have add a component template that is inheriting from the gh_compoment class which all of your components inherit from. In that template you’ll add a version check.

The version check can be done in numerous ways: check the version of the gha/DLL on local drive/server. Check a public file on GitHub for build date or version number or connect to a db.
Maybe through packagamanager if there’s an API to check version but I didn’t check.

The notification can be triggered with AddRunTimeMessage() in the component or even a quick popup with WPF window (or even winforms) if you’re on windows ( Find the MessageBox class on Google) or Etos if cross platform.

As for installation you can use package manager or if you don’t want your stuff public you can make a script that schedules a bat file to be run after you close rhino (as the files locally may be readonly while GH is running).There’s some events in rhino.rhinodoc and rhino.rhinoapp you may subscribe to. This can run a bat file that will copy the gha files from server to your local roaming/grasshopper folder. It gets tricky though if people both use the /libraries and 6.0/libraries and 7.0/libraries though. Not sure if there are smarter/easier workflows out there.

Oh and when checking for online or local network paths, always have a timeout and ideally have it run async. Otherwise it’ll kill your machine if you’re on a slow VPN etc.

And use a static bool that you set to true once the version check is performed, so it doesn’t check for updates every time you expire(run) your components, but only once per open rhino instance.

1 Like
3

Hi -

On Rhino 8, when you launch Rhino, a notification will pop up when an updated plug-in is available on the package server.
image
-wim

2 Likes
4

@wim will there be possibilities for a local package manager for private plugins?

5

Hej Mathias -

That’s already possible:

-wim

2 Likes
6

Awesome, so once it’s setup, we can use both the official and a private yak channel simultaneously, and get both notifications from both without changing settings later?

7

Hej -

I’m not sure which settings you’d be changing later, but, yes…
My screenshot of the G2 update was from a private server.
Our private server is significantly slower than the public server - perhaps @will has ideas around that one…
-wim

8

Thanks Mathias, I haven’t checked but is there any event fired before Rhino is loading the GH plugins? I could potentially have a version checker that listens to this event from another process and update the plugins before they get loaded. In this way the user has the latest when they open the GH file for the first time. Rather than when they close Rhino.

10
  1. Add the full path to your package repository folder, separating it from the default package server with a semi-colon, e.g. https://yak.rhino3d.com;C:\rhino_packages .

Where are these :point_up_2: settings stored? I couldn’t find in settings-Scheme__Default.xml or the Registry

11

Hi -

You are misquoting that section on the web page. On the web page, that section is the second step in the instructions on how to add a server. Your question is answered in the first step in those instructions.
-wim

12

Sorry, I realise that. What I mean is when we do that step one, where’s the setting actually stored on user’s machine? Reason I’m asking is if we want to go down this path, we’ll have to roll out the custom settings file for everyone so they don’t have to go through the steps individually. I was expecting these settings to be stored somewhere in an ini or xml file. Do I make sense?

Thanks.

13

Hi -

That makes sense, yes.
That setting is, indeed, stored in the settings-Scheme__Default.xml file:

      <child key="PackageManager">
        <entry key="Sources">https://yak.rhino3d.com;C:\rhino_packages</entry>
      </child>

Do note, however, that many settings are only recorded in that file when they are not set to their default values. So, as long as you only have the default yak.rhino3d.com server listed, their will be no <child key="PackageManager"> entry in that file.
-wim

3 Likes
14

I was refering to subscribing to both private and public servers/yak channels at the same time. So one hasnt got to switch between the two, to check for updates two places.

Looks like in your above reply this is indeed possible, very cool :slight_smile:

1 Like
15

@sonderskovmathias, that’s how we set up our internal plugins in the office to keep users up to date.

Just set up a batch script to modify the settings XML as described by @wim. Keep the default yak server and add a unc path to the local server where your private yak packages reside.

In the package manager your users will not be able to tell which plug-in comes from where. It just works. Also, it degrades nicely - if your local server is down or someone is working from home, the private plugins will not show up, but the official yak packages will still be accessible.

2 Likes