I recently noticed that Rhino 8, starting from version 8.12 (I think), now introducing .NET 8.
This immediately made me think about the possibility of finally enabling hot reload for my grasshopper component development on Mac. I felt confirmed when I read this:
Outside of Rhino, Hot Reload works on both platforms as of .NET 8.0 onwards, for Mac this means Visual Studio Code or other IDEs such as Rider.
Encouraged by this, I tested converting one of my plugins to target .NET 8 and enabled hot reload support in Rider. When I change the code, Rider correctly detects the changes and offers to apply them. However, when I rerun the plugin inside Rhino, I see no change in behavior.
Now my question: What am I missing?
Are there additional configuration steps needed, or is hot reload for in-process Rhino plugins still not fully functional yet?
I would assume that this is not going to work. Hot Reload is basically an in-memory modification of the IL layer. In the intended use-case, the IDE (Rider, VS) is hosting the application and you reload with help of the hosting mechanism.
A dll in Rhino is loaded by Rhino dynamically during Application Start and the IDE has nothing to do with this. All it does, it starts Rhino over shell when you press the play button. Or you attach the debugger to the running process.
When you debug the process, it observes the running process then for symbols being called, but this does not affect the logic in the process. Whenever you “patch” something it would require a reload of the dll from Rhino side.
Apart from that, I’m not using this feature very often. I have experienced strange behaviour, e.g. because states might not match. Its not uncommon to observe a problem which would not exist without using Hot-Reload. And often you see such problems, if a software is large and if its composed out of many .dlls. Just as Rhino. Also “unloading” is not trivial thing to do in NET. Even with all the changes of modern NET, like the introduction of the “AssemblyLoadContext”, a dll can not properly being unloaded under various circumstances. This can lead to really strange behaviour. So what if two versions of your plugin still exist within the Rhino process?
Chasing such bugs out-weights the benefit very often.
Thanks a lot for the detailed explanation, much appreciated! That’s a pity to hear since on windows i use it a fair bit, to quickly visualize the current state of geometry in my plugin.
Not sure if this is applicable to .NET8 or mac (I am doing this on windows and .NET framework), but what I do after making changes to my plugin to avoid having to restart Rhino is:
Build the plugin’s gha file. If you have other modules connected to it that need to be built, this will not work. If you have only done changes to the gha file itself, it does.
Go to Grasshopper and close all open documents.
Type GrasshopperReloadAssemblies in Rhino’s command line.