I’ve seen a lot of threads about debugging and having to restart Rhino between sessions. I’m curious if there’s any updated tips and tricks as we knock on 2020’s door.
Have the plugin act as a shim that dynamically loads assembly → Rebuild → Reattach to process?
Anything with Rhino Inside?
Before I saw your comment, I was able to get a reflection shim to work. I just cloned the plugin signatures and replaced the logic with:
It works with two copies of VS open. The first has the shim project and is attached to Rhino. The second has the actual plugin. You can rebuild the actual plugin and the shim loads the fresh compile when the next command executes.
The shim could be 100% generated using a plugin’s signature to stub out the reflection calls. I’m not sure why VS is locking the obj\Debug\ files, but deleting them before loading the bin\Debug files works.
And bonus points for using F#.
I think I’m going to keep going with this approach. You don’t have to do anything special to the actual plug-in using a debugger shim.
I’ll refactor and post the shim source in c#.
Man, I am rusty. A 10 yr hiatus from programming plus a new language = 16 hrs to get hello world with uninterrupted debugging.
This works perfectly. I put a c# shim template up on github.
There’s a couple of small quirks, so I also recorded a quick YT vid.
Basically you have a shim and a normal plugin. You want to load the shim and debug it. For the normal plugin, you want to disable it in Rhino through the _PluginManager (accidentally running the normal command will prevent you from rebuilding) and unload the project in VS (force it to use the debug symbols supplied through reflection).
@EricM I’ve just tested this for Rhino 7 and Visual Studio 2017, and it works great with the following tweaks.
EricM was using Rhino 7 WIP, so if you’re using a different version (Rhino 7, Rhino 8 WIP), you’ll need to change a few file paths:
Add the following assembly references for both
- C:\Program Files\Rhino 7\System\Eto.dll
- C:\Program Files\Rhino 7\System\Rhino.UI.dll
- C:\Program Files\Rhino 7\System\RhinoCommon.dll
PluginShim project properties → Debug → Start action → Start external program, update the path to
Everything else worked as described in his YT video–thanks EricM!
Not that it matters much for .NET, but we’re currently using Visual Studio 2019 to develop Rhino (already since some SR of 6).
Ah, thanks for letting me know.
I’ve just tested this for Visual Studio 2019, and the instructions are identical to my previous post. The
.sln file provided by EricM is for
VisualStudioVersion = 16.0.29613.14, which is 2019, so yeah, I was the one behind the times here.
Will it work for Grasshopper plugin?
I don’t use Grasshopper. Maybe @nathanletwory would know?
Sorry, I don’t trust edit&continue type of technologies. I prefer to close Rhino, compile my work and restart Rhino.
As such I have not tried any of the solutions that have been surfaced on our forum.
I don’t know if any of the other Rhino devs, or plug-in devs have used this technique in GH (or in Rhino for that matter). @stevebaer @DavidRutten @curtisw @dale anyone?
I do what @nathanletwory does…
To be fair, my shim isn’t edit and continue. It’s a full recompile to change something. You just don’t have to restart Rhino because the shim loads the freshly recompiled assembly.