PackageManager ID conflict on update

Rhino Developer
1

Hey developers,

when trying to update to a newer version of the plugin from a local yak repository, our users get an ‘ID already in use’ error. Uninstalling the existing version and installing the update works fine.

Is the plugin GUID supposed to change with each new release? We’re on a very fast release cycle and push updates a few times a week.

image
image996×589 35.3 KB

2

Seems that this thread is full of similar reports:

3

We’ve seen this error intermittently over the last year with our ZebraCut Plugin with both Rhino 7 and 8.
Though I’ve not seen it for a few months.

The last time I saw it I was able to confirm it was occurring because the user had 2 instances of Rhino open during the package update and I assume the uninstall fails because the plugin is in use in the other instance. Might be the same issue or might be entirely separate.

4

For us, it might be related to the fact that the plugin registers a panel which is open when users try to update. Still, it would be great if this could be resolved.

5

yes we also have such a panel. Our technical support teach to manually uninstall and then to install on Rhino 7. For Rhino 8 we’ve had no issues with the auto-update.

2 Likes
6

Morning all,

This should be fixed in Rhino 8. It seems it is for you @david.birch.uk ?

Plugins should maintain the same ID, it should never change. if you change it you’ll run into much more fun problems than you see above :wink:

The previous install is via yak, and the new one is also? Are you using Rhino 7 or 8?

7

Thanks @CallumSykes,

yes, the issue is in Rhino 7, both installs are via yak.
R8 works fine.

1 Like
8

I don’t believe a fix will be back-ported to 7, so an official fix is in Rhino 8. I’m not aware of a workaround myself for Rhino 7 unfortunately.

1 Like
9

yeah we’ve not seen any issues with Rhino 8 :slightly_smiling_face: I suspect it may still happen with 7 but we are not releasing very frequently for that as all our dev now is focused on v8.

10

What we had to do is set up our R7 deployments to happen via the CLI for yak.
We use something like this as a batch script that get’s run with Rhino closed.

"C:\Program Files\Rhino 7\System\yak.exe" uninstall "%PLUGIN_NAME"
"C:\Program Files\Rhino 7\System\yak.exe" install "%INSTALLDIR%\%PLUGIN_PACKAGE%"
1 Like
11

Interesting. And how do you share this with your users? Send them a link to a batch or an exe?

12

At the moment, we’re using a shared drive and they’re using the batch file directly. It’s a purely internal tool, so while this isn’t how I’d like to do it, it covers our use case.

Options we considered:

  • distribution via a shared drive (box / dropbox / onedrive / etc) <= what we’re currently doing
    • Batch files and *.yak files live here
    • Provides Limited Version Control
    • Only really suited for a small, internal user base
  • distribution via installers
    • Batch files and *.yak files are packaged into an installer
    • Installers are then distributed, downloads, links, etc.
    • This has the benefit of being something that a larger enterprise IT team will be used to accommodating, but you’ll probably need to set up the installers
    • This does not really work for a project that you’d like to distribute externally via Yak
    • I don’t recommend doing this unless there’s an existing distribution mechanism that requires you publish via this mechanism.
  • Share the batch file (either raw or inside of an installer), distribute the project via yak.
    • This is a good option if you’re distributing externally
    • For internal distribution follow this: Rhino - Custom Package Repositories
    • The installer / batch file then is there to provide a work around for R7 users, but you can probably avoid having to create new versions of the installer for every update and instead just publish to which ever package repository you’re using.

In general, doing all of the configuration management via the CLI means that when a user installs or updates rhino, I’m able to make sure they get the standard set of plugins that everyone else on the team works with. Not a huge concern if you’re making a plugin for external use, but its really saved us time internally.

2 Likes
13

Thanks for this comprehensive write-up @cullen.sarles!

Our company is quite large, with multiple offices around the world and we’re already using a custom yak repo on a shared drive. We also have an exe file on a shared drive, which automatically adds the necessary path to PackageManager’s settings. Rhino 8 has an auto-update feature which allows us to set things up once on user computers and then simply push updates to the shared repo.

We’re in the process of transitioning to R8, but for the foreseeable future need to support R7 as well.

1 Like
14

Sounds like you’re ahead of us in the process!

If you’re already using a custom yak repo, I’d just deploy the batch file as part of your install for Rhino 7 and push it out to those that already have it. It’d be manual in that users would need to run it, but it would at least make sure the install is happening correctly.

As far as having it behave more like the R8 auto-update, you could setup your own service on users machines that waits for all Rhino 7 instances to be closed and then run the update script if necessary. This may or may not be worth the effort as you’d need to prevent users from starting rhino while the update was running.

Good luck!

1 Like