Thanks - I was following the example that @fraguada posted in my own project however will try building the examples in the repo to see what the difference may be.
RhinoCommon.dll, RhinoInside.dll and Grasshopper.dll are all showing up in the Binaries/Managed folder after compiling.
That would be ideal as hot reloading is a great feature of UE4 and reduces the cycle time developing significantly as you go from minutes recompiling and reloading the editor to 10/20 secs (depending on complexity of what you’re doing)
I’ve built one of the samples following the (v well documented) guide from @fraguada to get up and running. The key things seem to be:
I also find there is a delay when the function is called which I assume is to do with the time it takes to open a head(er)less Rhino? (poor Rhino)
Glad the tutorial works!
In the samples, the first time the Play button is pressed is when Rhino and / or GH are started, hence the delay. Subsequent plays in the same session should not suffer from the delay since Rhino/GH should already be running.
They are well written that really helps.
We’ve been looking at ways to get around the hot reload issue which is a pain. Maybe we will need to dive down the rabbit hole of AppDomains (which isn’t something I’m yet familiar with), we were trying to find a way to split a VS project into two projects:
Assuming there are no changes made to the Rhino.Inside that needs a more traditional build process for, we were hoping that hot reload would still work for project 2. So far we’ve been struggling to get a second project in the same solution to play with USharp
@dagillespie We might have a way around this, which would be to use a similar strategy as what we are doing in the Unity Sample 2: How can I reference Grasshopper.dll assembly in Unity?
I’ll give this a try today with the unmodified USharp src. btw, can you give me an example of how you use hot reloading? I think I can get this to work with the unmodified source, but not sure I could test it properly without knowing the mechanics of hot reloading.
@dagillespie check the UE/Sample4. I haven’t tested if it works with unmodified USharp, but it doesn’t depend on any Grasshopper dlls (at least from the USharp perspective), which is what made us try to modify the USharp source.
Thanks!
I finally found some time to give it a try.
I struggle to run sample-1. I’m just blindly following so maybe I didn’t change something obvious. I just really want to see that Grasshopper geometry inside UE4! 
I downloaded RhinoCommon NuGet Package.
I’ve hit the wall pretty quickly - debbuging in VS.
‘Sample1.exe’ (CLR v4.0.30319: DefaultDomain): Loaded ‘C:\WINDOWS\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll’. Skipped loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled.
‘Sample1.exe’ (CLR v4.0.30319: DefaultDomain): Loaded ‘C:\Users\USER\Desktop\Rhino.Inside-Workshop-master\samples\Sample-1\bin\Debug\Sample1.exe’. Symbols loaded.
‘Sample1.exe’ (CLR v4.0.30319: Sample1.exe): Loaded ‘C:\Users\USER\Desktop\Rhino.Inside-Workshop-master\samples\Sample-1\bin\Debug\RhinoInside.dll’. Skipped loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled.
‘Sample1.exe’ (CLR v4.0.30319: Sample1.exe): Loaded ‘C:\Users\USER\Desktop\Rhino.Inside-Workshop-master\samples\Sample-1\bin\Debug\RhinoCommon.dll’. Skipped loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled.
‘Sample1.exe’ (CLR v4.0.30319: Sample1.exe): Loaded ‘C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Core\v4.0_4.0.0.0__b77a5c561934e089\System.Core.dll’. Skipped loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled.
‘Sample1.exe’ (CLR v4.0.30319: Sample1.exe): Loaded ‘C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System\v4.0_4.0.0.0__b77a5c561934e089\System.dll’. Skipped loading symbols. Module is optimized and the debugger option ‘Just My Code’ is enabled.
‘Sample1.exe’ (CLR v4.0.30319: Sample1.exe): Loaded ‘C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\mscorlib.resources\v4.0_4.0.0.0_pl_b77a5c561934e089\mscorlib.resources.dll’. Module was built without symbols.
Exception thrown: ‘System.DllNotFoundException’ in RhinoCommon.dll
The program ‘[5004] Sample1.exe’ has exited with code -1 (0xffffffff).
Which sample are you trying to follow (link)? Can you clone the repository and try to run the samples?
I am following the first one.
I cloned them but didn’t had luck with any of them. Spent my time mostly on trying to run Sample1.
I notice that both Rhino.Inside and RhinoCommon are referenced. Only Rhino.Inside should be in your references.
Put the x64 back to ‘Any CPU’, and make sure ‘Prefer 32-bit’ is unchecked.
It returns the same exception as previously.
Which version of Rhino 7 Wip do you have installed?
7.0.19302.12525
finally got it working.
I used the official uSharp repo, and changed the variable you mentioned manually. for some reason I get an error with the zip version you posted. Here’s the error, I checked the usharp wiki and it says it might be an issue with adding the unreal references to the project correctly.
love the sample Luis, it’s a really good start. I edited my blueprint so instead of loading the meshes continuously “on tick” which destroys the framerate, i hooked it up to a key press: my file loads the meshes when you press “P” you need to edit the actor to Auto Receive Input from Player 0, under details panel when you click on the Actor in the Editor.
@fraguada - Thanks I’ll check that example out.
Sure - hot reloading allows for a project to be built and code put back into the editor whilst it’s running rather than having to build and restart the engine after every change (unity effectively does this when you save your c# file). It really speeds up iteration time as you can modify and debug elements really quickly (and USharp hot reload is WAY faster than c# hot reload too).
