At some point GrasshopperReloadAsseblies stopped working for me. It does show an error if the grasshopper file is still open but doesn’t do a thing when grasshopper files are closed.
Version 6 SR11
(6.11.18348.17061, 12/14/2018)
Win 10 1803
There seems to be a connected problem with replacing GHA files in the Library folder. When Rhino is open I can’t replace any gha files anymore even if grasshopper is closed. To build a solution in Visual Studio I need to close Rhino.
I’ve cheked with windows Resorce monitor and it says that all files in the Library folder are used by Rhino.exe when grasshopper is open (even when empty). Other PCs with the same version of Rhino don’t show that the gha file is in use.
The best is if COFF is disabled. Loading from disk is the preferred solution. There are two problem with it though:
The dll is blocked in windows while it is in use, so you cannot delete or overwrite it.
The location the dll is loaded from is not trusted by Windows, which will prevent it from being loaded.
The first problem can be annoying while debugging, but since there are better ways to debug than “build-reload-test-does-it-work-this-time?” ideally you’d start there.
The second problem is there for a reason, loading through COFF to circumvent the security measures in Windows can be dangerous.
The problem with memory loaded dlls is that there is no way to unload an assembly from an appdomain, so once loaded, all you can do is load another one in its place without the first one really going away. It may contain all sorts of code which is still running somewhere. Also, if your assembly depends on other assemblies then they will not be found because the framework doesn’t know where the loaded assembly came from. So it won’t know where to look to find referenced assemblies.
