It’s a nightmare to see this:
“Dear expert user, the _GrasshopperUnloadPlugin command has been deactivated because reasons.
To be less facetious, it never really did what it claimed to do, and in the process of not-quite-doing-what-it-pretended-to-do caused more problems than it solved.
If you absolutely, positively need this feature in order to achieve and/or maintain a life worth living, please post something to this effect on https://discourse.mcneel.com/
We apologise for the inconvenience.”
Why?
I use this command to unload grasshopper and rebuild gha file no need to close the Rhino.
Without this command, I must close rhino and then rebuild gha file when change code of the gha file,Then open rhino.reload grasshooper,it’s too trouble,too trouble.
I hope this command back,back. Thank you. @dale @DavidRutten @stevebaer
Are you using Visual Studio 2017? I believe edit and continue should work.
I currently use GrassHopperUnloadPlugin a hundred times+ a day with Rhino5.
// Rolf
What problem does it solve for you?
Refreshing updated .gha during development, after compiling in VS.
// Rolf
But it’s not possible to hit breakpoints when the GHA is memory loaded is it? Wouldn’t that be a far bigger drawback during development than restarting Rhino?
Have you tried edit and continue? I believe it is working in the latest versions of Visual Studio
I’m using VS2015 Community.
I will try again, perhaps I have missed something, but I develop (VS) on a VM and run a batch file to copy to host (Rhino), so I doubt that it works…
Edit: Anyway, perhaps 2017 Community is preferred? I just grabbed VS2015 because the spec’s on GrassHopper development said so. …
// Rolf
Does debugging even work on a setup like that?
2017 is preferred. .NET development in general for Rhino is best on the latest version of the IDE / compiler tools
Well, I do have a copy of Rhino also on the VM, but apart from “logical debugging” I’m testing performance (on the Host) more often than I track down bugs.
I don’t do bugs. 
// Rolf
We use the method described below both for plugin and grasshopper. No need to close rhino when a plugin or gha needs to be recompiled.
Great that’s what I want ,Thank you Mr.Menno. Good Job!
Yes, Sometimes There is no need to debug, I just change some code of gha, and want rebuild gha and reload without restart rhino. but it’s impossible without _GrasshopperUnloadPlugin, Seem some master have better ways. I will study it .
Thank you for your reply dear stevebaer!
I develop plugins in a quite large office and sometimes I need to install them on people’s pc. When testing if something is wrong I can just unload grasshopper, copy the files again and load it.
I know the command wasn’t 100% perfect, but still useful. I would rather keep it buggy than not having it at all.
I added a new command to the next Wip called _GrasshopperReloadAssemblies which will unload all those GHA files that were memory loaded, and then immediately try to reload them. It doesn’t require that the Grasshopper window is closed and opened again, but it will not work while any Grasshopper files are loaded.
The command is classified as a ‘test’ command for the time being and thus will not autocomplete. It is impossible to properly unload an assembly from an AppDomain, but unless an assembly has registered event handlers or uses some sort of static caching, it shouldn’t matter that it remains loaded in the background.
Of course just like _GrasshopperUnloadPlugin, GHA files that were loaded from the disk rather than through memory cannot be replaced at all since they are locked by Windows while running.
Since this new command is far more specific in what it does, I’m hopeful it will not have the same problematic side effects the old _GrasshopperUnloadPlugin command did, especially with respect to Python.
Fair enough! Thanks!
O.o how could I live without this??? My workflow was unloadGH -> Build -> ReloadGH -> AttachToProcess…etc.
This one looks promising, I’ll try to test next week.
Thanks.
I know this is an older thread, but I want to point out that Edit and Continue does work in Visual Studio 2017 for .NET development.
Place a breakpoint in your component and when the debugger hits that breakpoint you should be able to edit your code and continue.
Hello @stevebaer,
How do you manage to Edit and Continue? It’d be awesome but I always get an error saying that “Changes are not allowed when unmanaged debugging is enabled”, as per screenshot below. Changing settings from COFF Loading to Disk doesn’t change anything.
I am using VS2017.
Hi @Xavier_Ayme,
Does your project have native code debugging enabled in the project’s Properties > Debug settings?
– Dale