Best way to license rhino.compute


I have a question about how you should think about the licenses for rhino compute. We are developing a system that will be using rhino compute as a part of it and I am curious about how we should think about the licensing aspect. We have set up a development server that runs windows 10 (not server) and we use a ordinary commercial license on this machine now during development. I have 2 questions:

  1. What are the rules for running rhino compute with a commercial license on a server that runs windows 10 (not the server version) ? Can it be used in the same way as the regular desktop version?

  2. Will any of you have a good solution for shutting down rhino when it is not in use when using the core-hour billing license? The system will be using short bursts of high computation relatively long intervals in between. This will be crazy expensive in relation to the actual core-hours used. Alternatively if you know if the guys at mcneel will release an update where it knows if the program is idle or actively running.


– Dale

Hello Dale!

Thanks for your quick reply! I actually came across this threat before I posted but I still wanted to clarify a few things because I think the answer is a bit vague.

Compute runs on desktop OS for testing and development purposes.

Since we’re building a new service, essentially everything we’re doing is testing and developing. I just wanted to know a bit more in detail if it is the OS or the way we work with the tools that’s the deciding factor.


This is actively being worked on and is available to play with today. There is now a top level ASP.NET 5 Core application named rhino.compute.exe in the project’s github repository. This application launches multiple child processes that are the actual Rhino.Inside implementations of compute. These child processes are what incur core hour billing and ask the parent process on a regular basis if it has received requests lately and will shut down if no requests have happened within a specific period of time. Later when new requests show up the parent process will start the child processes back up.

There is no documentation on this yet as we haven’t switched our own internal testing servers over to this process of running compute yet.


Hello Steve! Thank you for this, it seems like a really great project and I think it will benefit rhino compute a lot once it is out. Do you recommend us using this or waiting until it has been officially released?


Go ahead and use it. We don’t have documentation yet, but I do know that some people are already having success with the new system.

@stevebaer @erikforsberg95
Hi guys, I’m having trouble getting that new ASP.NET rhino.compute.exe app to run on our server. It simply starts and then closes so fast that I cannot see what is logged to the console (if anything).

Compute.geometry.exe is running successfully on the server (I can start it as a service OR start it as a process and both work fine with it responding to requests healthily).

Can anyone advise what might cause rhino.compute.exe to exit so quickly??
Is there a specific folder/path or env var it is expecting?

Server spec:

Hello @MonkeyFace,

are you running rhino.compute.exe directly on the VM or in a docker container?

We had some issues when trying to run compute.geometry in a docker container. Please see this thread for reference Docker file for rhino.compute.exe - #5 by erikforsberg95. ’

The issue we had was that a file called hostfxr.dll was not included when running
dotnet build instead of dotnet publish. I posted the whole docker file that we now use in that thread if that is useful.

Like I said, not sure if you’re running it in a container or straight on the machine but this might be worth looking into.


Directly on the VM.

Thanks for the reply - i’ll take a look to see if I can find the hostfxr.dll on our VM.

Ok let me know if that was the issue if you find it. A good way of ruling out that as the problem would be to run the debugger on the rhino compute (not compute geometry) repo on the server. Since the issue that I suggested only applies when the app is built (and not run in debug mode). Try that and see what the result is.


Thanks Erik, you put me on the right track … I needed to publish the Rhino.Compute solution as self contained so that all the dll dependencies are copied into the bin folder:

With all the dlls now present Rhino.Compute now starts up and is running:

However, I want it to listen on our url
I can see that I can change the port number from 5000 to something else, but how do i set it to listen to our main url instead of a localhost port?? I thought it might do it automatically by loading if from the RHINO_COMPUTE_URLS environment variable but it seems to ignore it.
In contrast when i start compute.geometry.exe by itself it does indeed listen on the url defined in RHINO_COMPUTE_URLS.
Am I missing a setting somewhere?


UPDATE: - i realised after posting that I need to set ISS port forwarding to forward inbound requests on our URL to localhost:5000 . … Now it’s working ! :slight_smile:


This is what I do for the embedded version of rhino.compute that I ship with Hops.

You should be able to pass a command line arg to set the port number

Thanks @stevebaer , Thanks @erikforsberg95

I realised after posting that I need to set ISS port forwarding to forward inbound requests on our URL to localhost:5000 . … Now it’s working ! :slight_smile:
I’ve edited my earlier post to mention that in case someone has similar issue.

Thanks for you’re posts on this @MonkeyFace. Managed to get rhino.compute.exe working by forwarding ISS to localhost:5000 also.
Wondering if anyone has managed to get this to work with Rhino Compute AppServer in addition to just Compute? Compute will receive and process the requests from Appserver OK however the response from Compute does not appear to get back to the AppServer as far as I can determine.