I have recently converted my plugin from using an INNO installer to using the RHI installer system. However, it seems like a step backwards. Once you have converted your plugin to use an RHI installer - testing and debugging becomes much more tedious. You need to compile you plugin and then manually copy it into the RHI installer destination folder (ie. C:\Program Files\Common Files\McNeel\Rhinoceros\5.0\Plug-ins\OctaneRenderForRhino (f109bd23-4cf3-4c0b-9f83-06be474b0152)\2.24.1.47\RHI Installer\Rhino 5.0\x64 in my case), or update the post-compilation process to do so - in which case you need to run VS as Admin. And if you frequently update the .NET AssemblyVersion as I do, your plugin’s destination folder will keep changing. So my procedure when updating the AssemblyVersion is, compile into a temp folder, copy temp folder rhp file into the installer folder structure, create ZIP, rename to RHI, install. Then if whatever code change made is not right, or you want to debug, re-compile and manually copy into the RHI destination folder.
In summary, when activity working on a plugin, doing so with the above constraints to a pain. Perhaps there is a better workflow that I am not seeing?
You don’t need to keep installing the plugin while developing. Just drag the RHP from the build folder onto rhino once. After that, rhino knows to load your plugin the next time it starts.
Then when you want to update the version with your users, update the version number and create an installer.
There are a bunch of additional dll’s that my plugin loads - so unfortunately I dont think it’s that simple. Plus, if I install the plugin from the dev folder, how do I then test the final installer version? I would need to uninstall the dev version? When a plugin has been installed twice (ie. a dev version and an installer version) it’s a but unclear which one will get loaded. I had had to delete all the dev version files in order to get the installer version to load.
There are a bunch of additional dll’s that my plugin loads - so unfortunately I dont think it’s that simple.
We use this method where we have 18 plug-ins, supported by 43 additional DLL’s. For us, it works well.
In our case we don’t get multiple installed plug-ins, but we don’t use the RHI installer, so that may behave differently. However, we frequently use the program below to “clean” the registry of all information about our plug-ins, just to be sure that whatever is being installed by the installer or by dragging is the correct set of plug-ins.
Note that it is very much tuned to our specific uses:
it only looks at 64-bit Rhino
it checks the Address entry of the plug-in registry to see if it matches ours using a regular expression "PO.Box.28.*Wageningen" - this is the value entered in the AssemblyInfo.cs for [assembly: PlugInDescription(DescriptionType.Address, "Your address here")];
Latest remark: for some reason, in our case, the program needs to be run twice. I have no idea why.
using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Threading;
using Microsoft.Win32;
namespace RhinoCleanRegistry
{
public static class Program
{
public static void Main(String[] args)
{
RegistryKey hkcu = Registry.CurrentUser;
RegistryKey pluginsBase = hkcu.OpenSubKey(@"Software\McNeel\Rhinoceros\5.0x64\Plug-Ins\", true); // only 64-bit Rhino
if (null == pluginsBase)
{
Log(@"Could not find registry key 'HKEY_CURRENT_USER\Software\McNeel\Rhinoceros\5.0x64\Plug-Ins\'");
Log(@"Is Rhino 64-bit installed?");
return;
}
String[] subkeyNames = pluginsBase.GetSubKeyNames();
foreach(string sub in subkeyNames)
{
RegistryKey pluginKey = pluginsBase.OpenSubKey(sub, true);
if (null == pluginKey)
continue;
object addr = pluginKey.GetValue("Address");
String address = addr as String;
if (null != address)
{
Regex r = new Regex(@"PO.Box.28.*Wageningen", RegexOptions.Singleline); // Put your own address here!!
Match m = r.Match(address);
if (m.Success)
{
object name = pluginKey.GetValue("Name");
Log("Removing {0}", name);
RemoveKey(pluginsBase, sub);
}
}
}
Console.WriteLine("Press ENTER to end the program.");
Console.ReadLine();
}
public static void RemoveKey(RegistryKey baseKey, String subKey)
{
RegistryKey sub = baseKey.OpenSubKey(subKey, true);
if (sub == null)
return;
if (sub.SubKeyCount == 0)
baseKey.DeleteSubKey(subKey);
else
{
foreach(String subsub in sub.GetSubKeyNames())
RemoveKey(sub, subsub);
}
}
private static void Log(String format, params object[] values)
{
Console.WriteLine(format, values);
}
}
}
Thanks for the reg cleaning app - that will be useful. I will also try dragging the dev rhi file into Rhino to see it it then overrides the current installed RHI version - if it does - that will certainly help.
My workflow is a little different to yours, in that a) I need to increment the version number when starting a new versions code (since there are interim builds for testers - done using INNO installer from the dev folder - and these version generally use a different version of the linked in dll’s - so it’s essential these dll’s are read from the dev folder rather than the RHI destination folder), and b) I need to run the RHI installer prior to each release to ensure I have the correct matching versions of the dll that the plugin loads. So it is more complex to use the RHI installer rather than simply use INNO on the dev folder - but I’ll get my head around it
