I saw several threads on this (old threads).
Could someone explain the reason why such functionality is not yet available?
Is it due to “it being in progress”?
Is it due to “it being ignored”?
Is it due to “permanent limitation”?
I just found a new way to crash grasshopper, and I do not want to restart Rhino every time this happens.
Thanks
It’s not possible to unload an assembly from an AppDomain in the .NET framework.
Once a program is loaded and running, any plugins it loads as part of the process remain loaded until Windows can wipe the entire memory space associated with the application (in this case Rhino.exe), which only happens when the app quits.
What sort of crash are you getting? It’s clearly not a full-blown crash because you still have control over Rhino. What state is Grasshopper in?
the state is I can save/open but I cannot use the mouse in the canvas.
This happens when I use the button component attached to a component.
Since the button causes the component to expire both on down and up position, I guess this causes confusion in grasshopper as the component is expired second time before it completes the operation from the first expire.
I don’t know if you understand or if I explain it properly.
I’ll prepare something and upload a .gh that reproduces the issue, but later because I don’t want to restart Rhino right now 
Here @DavidRutten, run this:
issue_button.gh (13.7 KB)
the script is taken from this thread (Ghpython executing rhino command and get the result inside grasshopper?) and I simply added the button to trigger (expire) the solution. But because it does it twice (button down and button up) grasshopper hangs.
if you hold the button to complete, then release to complete again. GH will not hang.
About that, I was wondering why isn’t GH running as a separate process? But I guess then in order to use Rhino you’ll have to connect via COM to it. Am I correct?
Or some other pipeline tech. WPF probably given we’re doing this in .NET
Mutli-process does increase complexity here. If so, any plugin that uses API from Rhino itself needs to communicate with the Rhino process, which might require a full remake of RhinoCommon.
The more practical way might be loading Grasshopper and its consequential modules in a separated AppDomain. Since RhinoCommon communicates with the native C interface eventually. There shouldn’t be a problem to be running in another AppDomain, as long as it has sufficient privledges.
Considering how many plugins there are already perhaps that’s necessary. You don’t want to restart rhino just because a single plugin has crashed in some way.