Rhi compiled PlugIn installer issue

[clement]

Hi @will and @brian,

i recently had to compile a bunch of scripts using the RhinoScriptCompiler second edition which creates *.rhi files of my Plugins and found that when they are installed, any previous installed versions of the same PlugIn are not removed. The installer seems to automatically add version specific folders on its own eg. the first installed plugin has this folder:

C:\Users\Clement\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\PluginName\1.01.0234

then the next installation creates a new version folder like so:

C:\Users\Clement\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\PluginName\1.03.0143

So it leaves the first version folder including its contents and the user (or me) is having many versions of the plugin, including the referenced files in these folders like toolbars etc. It also makes it very difficult when Rhino opens after installation of the plugin to find out which version of the deployed toolbar is now loaded.

Could you add an installer option so the user can decide that any previous install of the same PlugIn is removed ?

_
c.

[brian (Brian Gillespie)]

That’s the design intent of .RHI - to have a couple versions on there for rolling back.

And it’s supposed to change the plug-in registration so that Rhino only ever sees the newest one.

Can you tell me more about

@clement

So it leaves the first version folder including its contents and the user (or me) is having many versions of the plugin, including the referenced files in these folders like toolbars etc. It also makes it very difficult when Rhino opens after installation of the plugin to find out which version of the deployed toolbar is now loaded.

How are you trying to determine which version is deployed?

[clement]

@brian

That’s the design intent of .RHI - to have a couple versions on there for rolling back.

Hi @brian, if this is the design intend, why is there no option to roll back when an installer is started and an existing previous installation is found ?

@brian

How are you trying to determine which version is deployed?

Good question, i cannot because the folders created are having versions numbers which seem to be random and cannot be controlled by the developer. Imagine a developer is having a larger sized plugin file and he packs additional files with the rhi plugin installer. How does he avoid that the end user has redundant data when he updates the plugin ? Why is the version number increased at all if the user just re-runs an “updated” plugin installer because the toolbar or documentation has been updated ?

I really see no purpose in keeping the last 40 installs. A rollback can only be performed manually but how should that work from the user side ? If the user deletes manually the last installed plugin, is the registry still pointing to it and does Rhino automatically know which of the remaining plugins is loaded next ?

My suggestion would be to just remove the version number folders completely and let the developer control this using the folder stucture in the rhi file to make the process more transparent and an existing plugin including toolbars etc. can be safely overwritten. Or maybe add an option that this is done by the installer in the RhinoScriptCompiler.

_
c.

[will (Will Pearson)]

The Rhino Installer Engine only keeps two older versions around; the rest are cleaned up.

For regular C++ and .NET plug-ins the version number is controlled by the developer. The script compiler auto-generates a new version number each time you build a new version of the plug-in.

@clement

Why is the version number increased at all if the user just re-runs an “updated” plugin installer because the toolbar or documentation has been updated ?

In my opinion this is good practice. If anything changes then the version number should be updated to reflect that this is a new release.

@clement

If the user deletes manually the last installed plugin, is the registry still pointing to it and does Rhino automatically know which of the remaining plugins is loaded next ?

Rhino uses the registry to maintain a list of which plug-ins to load and their paths. If one is missing then it simply won’t load it.

Unfortunately, there’s only so much that the script compiler is designed to do. For complete control there’s always the option of creating your own plugin/installer. The script compiler has an option to “generate source for the current project”. You can then incorporate this into a regular C# plug-in project and control the version number (by editing AssemblyInfo.cs).

I’m hoping to resolve some of these versioning issues with the new Rhino Package Manager (see #serengeti:yak).

All of that said, what are you trying to do that requires knowing the current version? If we know this then we can try to help.

[clement]

Hi @will, thanks for your detailed response.

@will

The Rhino Installer Engine only keeps two older versions around; the rest are cleaned up.

Please mention this in the help page for the Installer Engine.

@will

The script compiler auto-generates a new version number each time you build a new version of the plug-in.

The autogenerated number is what i found confusing at best. On a first install, i got this number: 1.0.7106.33644. The next number it generates is higher but not consecutive. Best would be to control this number using the RhinoScriptCompiler but there is no option yet to do so. If there would be such an option, i could simply ensure that the previous plugin installation is safely overwritten. At the moment i am using the “Message” filed to find out if a new version install actually worked or not.

I’ve found the following issue:

1. Compile a plugin from a bunch of scripts
2. Create a zip file from the plugin, a toolbar and pdf help file
3. Rename the zip to rhi and install it (this is the first install)

Now i have to update the pdf help file. I rename the rhi file to zip in order to include the new pdf helpfile with the installer. Then i rename the zip to rhi and try to install again (the plugin file has not been changed). The result is an unexpected error during installation:

but the help file has been updated (overwritten) in the plugin installation folder Imho this is very confusing for the user. If i recompile the plugin, then create my installer (rhi) and install, a new folder is created with a random version number. The previous install of the plugin (and the outdated helpfile) remains on the users hdd. I want to avoid this.

@will

The script compiler has an option to “generate source for the current project”. You can then incorporate this into a regular C# plug-in project and control the version number (by editing AssemblyInfo.cs).

My question is about using the plugin installer engine with the RhinoScriptCompiler only. I do not have access to VS.

@will

what are you trying to do that requires knowing the current version?

I am trying to avoid that users have multiple versions of my plugin installed at the same time. I would like to ensure that when i install an updated version of my plugin, the previous version (including the files which where installed with the rhi, is/are removed).

The information on this page recommends to create a folder structure to control for which Rhino version a plugin is installed. I created this folder structure for the rhi file:

|-- Rhino 6
|-- |-- x64
|-- |-- |-- MyPlugin.rhp
|-- |-- |-- MyToolbar.rui

The end result is this install location:

C:\Users\Clement\AppData\Roaming\McNeel\Rhinoceros\6.0\Plug-ins\MyPlugin (4bbfcc78-4311-c616-895d-abba4f495eff)\1.0.7106.33644\Rhino 6\x64\

My toolbar contains eg. a button to run (open) the pdf helpfile which resides in the plugin installation folder. Imagine what i have to do in my compiled script (the command which opens the helpfile), to find out the proper path of the pdf helpfile when multiple versions are installed at the same time.

_
c.

[will (Will Pearson)]

I’ll have a think about this and get back to you. I wonder if @dale might have a few ideas too…

[brian (Brian Gillespie)]

@clement

The autogenerated number is what i found confusing at best. On a first install, i got this number: 1.0.7106.33644 . The next number it generates is higher but not consecutive.

This number is generated based on the date and time, it is not random. This is the .NET framework’s preferred method for auto-generating version numbers at compile time.