Eto support in all Rhinos

Hi @stevebaer, thanks for taking a look. If i run below in Rhino5 x64:

import clr, sys

sys.path.append(r"C:\Program Files\Rhino WIP\System")

import Eto
from Eto import *
from Eto.Forms import *
from Eto.Drawing import *

platform = Eto.Wpf.Platform()
app = Eto.Forms.Application(platform)

i get this error:

Message: attribute 'Wpf' of 'namespace#' object is read-only

Could you try it from the built in PythonScript editor in Rhino 5 ?


I can test this tomorrow, but in the meantime try adding a reference to Eto.Wpf.dll also

Hi @stevebaer, ok. If i add the dll it tells me that an assembly with strong name is required.


ok; I’ll have to try this out and get back to you.

1 Like

Update: not having a whole lot of luck hacking in the use of the V6 Eto DLLs. I suspect a separate installation of Eto would be required. I haven’t tried this yet.

Hi Steve, thank you for taking the time to get this working. I’ll stick with WinForms for now which i stil like a lot.


I had time today to look at this, and the problem basically is that Rhino 5 comes with a different version of Microsof.WindowsApiCodePack.Shell.dll which is not strongly named (and appears to be a custom build), whereas Eto.Wpf.dll requires the publicly available version from nuget ( which is strongly named.

I’ve been able to get it to work by renaming Microsof.WindowsApiCodePack.Shell.dll in the Rhino v5 folder to something else to verify this, but I am unaware what consequence that would be to the stability of Rhino in general (e.g. other things might not work).

Basically, because of this conflict, Eto will unfortunately not be able to run in Rhino v5 as is.

I was running into the same problems when trying to put a python sample together.

We use WindowApiCodePack for the file open dialog which is critical to Rhino. Do not modify this file

Here is an example that demonstrates how to display an Eto form in a docking panel.

@dale This has helped me! Thanks and well done!

Here’s a working link:

– Dale

A post was split to a new topic: Using Eto in Rhino 5 for Windows

where can i find this code now? I need to backport a rhino7 plugin to rhino5. Any leads i am also stuck at the System.InvalidOperationException: ‘Platform instance is null. Have you created your application?’ part

i can run the form as an Application().run but it then fails after that and suspect because of how its invoked.

Try new Application().Attach() instead of Run(). If it’s going to run on newer Rhinos with Eto, make sure that Application.Instance is null before doing so otherwise you may break default behaviour.

Hope this helps!

1 Like

Thanks gave that a go, but form does not load with attach, ir DOES with .RUn, however in debugging i have to dismiss this warning multiple times which i suspect is the error , sadly i have no idea what its trying to tell me.

Managed Debugging Assistant ‘DisconnectedContext’ : ‘Transition into COM context 0xe92390 for this RuntimeCallableWrapper failed with the following error: The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)). This is typically because the COM context 0xe92390 where this RuntimeCallableWrapper was created has been disconnected or it is busy doing something else. Releasing the interfaces from the current COM context (COM context 0xe924b8). This may cause corruption or data loss. To avoid this problem, please ensure that all COM contexts/apartments/threads stay alive and are available for context transition, until the application is completely done with the RuntimeCallableWrappers that represents COM components that live inside them.’

a squizz around the interwebs says

" You are calling a interface (gui) component outside of the thread that created it. A invoke with a delegate would be a quick (and somewhat dirty) fix. A better idea would be to separate your gui stuff from your logic.– [Nick Otten]"

All thsi same code works fine in Rhino7 though so suspect its how ETO is being called.

@chris.botha are you running your code in a non-UI thread? You need to simply do:

if (Application.Instance == null)
  new Application(Eto.Platforms.Wpf).Attach(); // being explicit on the platform to load

var myForm = new Form();
// init myForm

We’ve done a lot of work to integrate Eto into Rhino 6 and beyond which make things work better, so there are still going to be many caveats to doing this. I’ve also put together a little sample here showing how to set it up. Hope this helps! (30.0 KB)


many thanks that worked to get rid of the warnings,
runing the same in both versions now.

1 Like

in a sideways note… I am having to do this legacy build because a certain jewellery plugin lost its way after rhino 5 , and that company now deliver buggy broken software with 60% of the tools of its older self. So I have a bunch of users refusing to use it, and ergo im forced to make legacy builds.

However… that software is also ridiculously easy to find cracked… but… the cracks work by stopping the platform and rhino from checking if they are legit… meaning my application ALSO cannot call home to deposit files… as its just part of “rhino”

Any idea how I can circumvent this issue and make my eto.form still speak to rhino while registering to the firewall and windows as a seperate application that CAN get past the blocks,


Can I tell by code when a copy of Rhino is cracked, so that I can display an error message related to it? (and maybe build a standalone uploader based on unity et al to handle the files)

Hi @chris.botha,

I’m confused what you are asking for? Do you want help running your plug-in in cracked Rhinos?

– Dale

hmm rereading that i get why you confused, ok ill ask it more simply,

how i can detect if my software running in a cracked rhino so I can offer an alternate solution.