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
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.