We are trying to launch Rhino with new Rhino.Runtime.InProcess.RhinoCore() within an .net core app on a virtual windows machine hosted on Amazon EC2. We added the Rhino.Inside package that runs RhinoInside.Resolver.Initialize(); at the start of Program.cs which loads the dlls. We have configured a RHINO_TOKEN in the system environment variables with the auth token that we fetched from the core hour billing and the latest version of rhino 7 is installed on the virtual machine
The program is able to start but whenever we try and reach for our endpoint, the app returns that error and exists without any log or anything.
Hi @Antoine_Bouchard My apologies for the delay. I was wondering if we could confirm that your licensing is indeed setup properly. Your description above does make it sound like it’s setup correctly, but this would at least help us rule out if licensing is the issue, or if it’s something else.
I was wondering if you could install the latest version of rhino.compute on your VM. Just download the zip file, extract the contents somewhere, and then open the rhino.compute directory and launch the rhino.compute.exe. You should see a console window appear, however, it likely won’t try to launch Rhino/Grasshopper in the background until you send it a valid HTTP request. You can use Postman or some other HTTP client (Chrome could work too) to send an GET request to your VM. If you’re sending the request on the same local VM, you can send something like: http://localhost:5000/activechildren. When you launch the rhino.compute.exe, the console window should tell you what port it is listening on (I believe the default port is 5000 in this instance)… so that’s the number to include after localhost… and the /activechildren endpoint is one of the predefined endpoints which will automatically spin up the child process (compute.geometry.exe). You may also need to include your API key in the HTTP header if you’ve also defined that in your environment variables.
Once you’ve sent a valid request, you should then see the rhino.compute console window printing out new statements, with some of them saying it’s “Loading Rhino” or “Loading Plugins”. If that all works and you get that far, then I think we can assume it’s not a licensing issue and it is something else that’s causing the issue you’re seeing.
We ran the rhino.compute.exe without an issue. The http://localhost:5000/activechildren query works fine on the VM which confirms as you stated that it’s not a licensing issue, it’s probably something we’ve done in our .net core projects. One thing that could be important to know is that we are trying to separate the project’s responsibility in different csproj where our RhinoInside.Resolver.Initialize is running in the “Program.cs” of our webapi which will then connect to our RhinoService.csproj via Dependancy injection. If the loading of the dlls will prevent this kind of segregation of projects, we will merge it back together but we’d want to avoid doing so.
Thanks for the quick reply. I’m glad to hear it’s not a license issue. However, that also means it’s a little more tricky to debug. Is there any chance you could create a simple project example that you could share with us so we could have a look on our end? Basically, whatever the minimum would be to reproduce the issue. We don’t need any of your proprietary logic, just something that’s representative of your project structure so we can review on our end.
I was wondering, would we be able to launch rhino with a regular license on the windows server VM? I’m asking because I remember trying it and being able to launch rhino, adding a license (connecting to my account) on the VM and I’m wondering if that could be the issue.
Thanks for this. We’ll begin looking into this.
As for the license question… no, you should not be able to use a standard license on any machine running Windows Server. Those machines should require a core-hour-billing license. If you find this is not the case, we’d love to know about it.
Ok. As I mentioned we are looking into this, but there may be some issues with targeting .NET 7.0 in the current solution that you provided. We’re going to try to see if this will work or if we need to modify something on our end to get this to work.
In the meantime, you may want to look at how we have setup rhino.compute to be launched via Hops/Grasshopper. The pertinent code lives here in Servers.cs. Basically we have a separate process which ends up handling the launching of rhino.compute… And then you have to configure your project setup to be able to communicate between the two projects via out-of-process hosting. Hopefully that makes sense, but perhaps you can look into our Hops/Rhino.compute directory to get a better sense of how we’ve set this up.
@Antoine_Bouchard Good news. After having a few different developers have a look at this issue, I think we have a working solution. While this does appear to be working with Rhino 7, if there are things that you end up needing which don’t work, we may have to get you to switch to Rhino 8 - after we update it to work with Rhino.Inside in .NET Core. But, please have a look at this sample and let me know if this helps solve your issue. Cheers. VirtualRhino-working.zip (319.9 KB)
Hello!
I’ve been looking at the Servers.cs that you previously linked, which helped understanding the basis of the process management which I wished to avoid having to do myself, although I could have reused the open sourced code. I’ll be looking at the .zip file that you provided, thank you!
For your question about the Rhino 7 running on the Windows Server machine, I simply downloaded the Rhino 7 installer, and I used an evaluation license when the launcher prompted me to add a license. Rhino just opened after that, like it would on a regular machine. The OS is Windows_Server-2019-English-Full-Base-2022.12.28, but I can’t recall which instance I used on Aws.EC2.
