Double-clicking RHP doesn't load in V6

Rhino Developer
1

Hi @brian and @will,

i want to report a bug relatated to installing a compiled script (a PlugIn in *.rhp file compiled with the RhinoScriptCompiler). After compiling my script using the RhinoCommon.dll for Rhino 6 as SDK version. The result is an rhp file.

If the rhp file is double clicked (without any Rhino open), it opens Rhino 5 and shows this error message:

CompiledScriptPlugInFileInstallError :

It looks like installing an rhp by double click is broken, it worked with rhp files compiled for V5. Note: this is not related to installing rhi files.

_
c.

2

Thanks, I logged this as https://mcneel.myjetbrains.com/youtrack/issue/RH-54363

There are about a thousand ways that RHI installation can go wrong, especially with file associations. My guess is that the file association on your computer is incorrect, and would be fixed by running RhiFix:
https://wiki.mcneel.com/rhino/5/rhi-problems

3

Hi @brian, i did not change anything about file association. It’s just happening when you have V5 and V6 installed at the same time.

_
c.

4

I know… did you try running RhiFix anyway? Did you install Rhino 5 more recently than Rhino 6?

5

Hi @Brian, no i did not run RhiFix yet as i wanted to preserve the state locally that my clients may experience.

No, RH6 has been the most recent installation.

EDIT: @brian, Changed title to “Double-clicking RHP doesn’t load in V6”

_
c.

6

Ah, good point… this is actually not related to RHI as I initially suspected, it’s related to Rhino’s association with opening RHP files. I’m just reading and responding too quickly. What happens if you zip your RHP and rename the ZIP to RHI? Does it install properly?

It looks like the file association between Rhino 6 and double-clicking RHP files isn’t present.

7

When I double-click an RHP, it asks me which version of Rhino I want to use, and then lets me specify a default for next time. I bet you did this long ago with V5. This is another reason that RHI may be a better distribution method for you.

8

Well, yes and no. It then installs for V6 and V7 which i need to prevent. As long as the rhi installers do not allow to set this i cannot use them.

that is the thing.

Not here unfortunately. Please see the first post what happens on my side.

_
c.

9

Is that on a clean computer with a newly installed Rhino 5 and 6? Or is there a possibility that in the distant past, you accepted Rhino 5 as the default app for double-clicking an RHP in Windows Explorer?

10

Hi @brian, no, it is an older system. It could be possible of course that the message has been accepted a long time ago. But it must have been before Rhino 6 was installed.

_
c.

11

Another installation method for .rhp files is to drag and drop them onto a running instance of Rhino. This way you can be certain of the version for which you’re registering the plug-in.

12

Thanks @will, it is not me beeing unable to install an rhp file for the correct Rhino version. I just reported what happened to one of the receipients of one of my plugins. I was able to repeat in on my system.

I usually advice to close Rhino and double click an rhi file instead after removing previous versions manually in case the plugin has been installed before to prevent various problems. But since there is no control to which version the rhi installs when Rhino 5,6,7 is installed, i started sending out the plugin files in rhp format along with a textual instruction on how to unblock the file, open the correct Rhino version, run the _PluginManager command and then click on the install button. However, you never know if the user really reads through your instructions. This was the case and the user just thought to use double click on that icon, which looked similar to a rhino file icon …

_
c.

13

Just ran into this while trying to diagnose why .rhi does not work on my win10 machine (Rhino 5 & 6 are installed, 7 has never been). Found posts here about RhiFix.exe and tried it multiple times, with reboots in-between just to be sure, to no avail. Then found this topic, and confirmed that .rhp was opening with Rhino 5. Tried to associate .rhp with Rhino 6 multiple times (both via Explorer > Open With and Windows Settings > Default Apps), still no dice – they continued to be opened in Rhino 5. So, time to root around the registry, where for .rhp I find this:

image

Scrolling down, and renaming those:

image

Now .rhp opens successfully with Rhino 6 from Explorer, but .rhi is still not working. Run RhiFix.exe yet again, still no change. Reboot, still not working. Repair Rhino 6, still rhiexec complains:

image

Checking Rhino 6 > File > Properties > Updated & Statistics, it reports “This Rhino is up-to-date.” Help > About Rhinoceros reports Version 6 SR20
(6.20.19322.20361, 11/18/2019), and Properties > Details for C:\Program Files\Mcneel\Rhino Installer Engine\x64\rhiexec.exe reports File Version 6.20.19322.20361.

The .rhi I am testing with contains only my .rhp, which works fine, and which ILSpy confirms as referencing RhinoCommon and Rhino.UI version 6.20.19322.20361. Just to be sure, the .rhp is not in any subdirectory in the zip, and the .rhi is created just by right-clicking the .rhp > Send To > Compressed (zipped) Folder, and renaming to .rhi, to rule out issues potentially caused by a 3rd-party zip program.

So what next … let’s figure out if we can get any info from rhiexec. Try rhiexec /? in a command prompt, nothing. Use ILSpy to see whether there may be a log. Looks like there should be, so use procmon to see where rhiexec is writing to, turns out to be appdata/roaming/mcneel/rhinoceros/6.0/logs. Open the associated log to find the reason it is not working:

12/06/2019 08:04:07	4364	Info	Initializing	Initializing Installer	(0%)
12/06/2019 08:04:07	7832	Error	Exception: System.IO.FileLoadException
          Message: Cannot resolve dependency to assembly 'bella_dotnet, Version=19.7.0.0, Culture=neutral, PublicKeyToken=null' because it has not been preloaded. When using the ReflectionOnly APIs, dependent assemblies must be pre-loaded or loaded on demand through the ReflectionOnlyAssemblyResolve event.
          Source: mscorlib
          StackTrace:    at System.ModuleHandle.ResolveMethod(RuntimeModule module, Int32 methodToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount)
             at System.ModuleHandle.ResolveMethodHandleInternalCore(RuntimeModule module, Int32 methodToken, IntPtr[] typeInstantiationContext, Int32 typeInstCount, IntPtr[] methodInstantiationContext, Int32 methodInstCount)
             at System.ModuleHandle.ResolveMethodHandleInternal(RuntimeModule module, Int32 methodToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext)
             at System.Reflection.CustomAttributeData..ctor(RuntimeModule scope, CustomAttributeRecord caRecord)
             at System.Reflection.CustomAttributeData.GetCustomAttributes(RuntimeModule module, Int32 tkTarget)
             at System.Reflection.CustomAttributeData.GetCustomAttributesInternal(RuntimeAssembly target)
             at RhiExec.PluginInfo.GetPluginAttributes(AsyncReporter reporter)
             at RhiExec.PluginInfo.InspectPlugin(String rhp_file, AsyncReporter reporter)
             at RhiExec.InstallerPlugin.InspectPlugin(String PathToPlugin, AsyncReporter reporter)
             at RhiExec.Program.Main(String[] args)

So of course it cannot install my rhp because it cannot load a dependency. But I try again with an .rhi with the necessary dependencies, and it still does not work. Look around a bit more and find appdata/local/temp/rhiexec, which appears to be where rhiexec puts .rhp files to install them, and looking in the temporary directory that is created while rhiexec is running, I see it contains only my .rhp, and not any of its dependencies. So I guess that is the reason.

I hope it helps.

14

Turns out that is not the reason, per se, and that it is actually a bit more interesting.

I made a test project like mine, with render plugin, dotnet wrapper, and native library, to send to you guys – but that one worked. Racked my brain to try and find what could be the difference between them.

So it was time for fuslogvw, and I see that while my wrapper dll is loaded during rhiexec’s running, the corresponding one is not loaded, when installing the test project. Well, that makes very little sense.

So it’s ILSpy time again, to see what is going on in that stack trace. I know you’re going to be doing reflection-only load for this, so how on earth is this dll trying to get loaded? Have you guessed it yet?

It’s crashing somewhere in the framework’s GetCustomAttributes.

And I have a custom attribute, AssemblyBuildDate – and of course it is implemented in the other dll.

15

Hey @jdhill, thanks for all the digging you’ve done already. The custom attribute does seem to be the issue. I’ll investigate a fix, though this will only work for users of the next Rhino 6 service release. Is there any chance you could remove the custom attribute or move it into the plug-in assembly?

16

Yep, that’ll be my workaround.