Eto cross-platform development

Serengeti (Rhino WIP) Developer
1

We have developed some Eto forms using libraries compiled from github source. I want to use some of these forms in a Rhino plugin, but the dll versions are different and the WIP only includes Eto, Eto.WPF, and Eto.Serialization.Xaml. The Eto.Winforms is needed for some applications. I would like to avoid having duplicate code or projects. Would it be possible to either: A) include the source/version of Eto that comes with Rhino WIP or B) get all compiled libraries for development and testing? Any other ideas or suggestions are welcome.

2

Hi Piotr,

I’m confused why you need Eto.Winforms. What does it have that Eto.WPF does not?

Basically, all you plug-in should need to do is reference Eto, as Rhino will handle the platform-specific reference to Eto.WPF or Eto.Mac.

There are some Eto samples in the WIP developers repo on GitHub if you need.

https://github.com/mcneel/rhino-developer-samples/tree/wip/rhinocommon/cs

– Dale

3

Hi Dale,

Thanks for the reply. I’m new to the discourse feature and didn’t get any notification until logging back in just now.

Anyways, I’ll try to explain the need for Eto.Winforms. We have developed some other tools (outside of Rhino plugin Orca3D) that are based on Eto and target various platforms. The core functionality, only dependent on the Eto dll, have been moved to their own library and used as references in multiple applications. That’s where the issue comes in. If I target these core functions to use the library from Eto (compiled from github), then all of the outside applications work but the Rhino plugin does not. If I use the Rhino WIP version of Eto, then the Rhino plugin works, but other applications do not. Since the Orca3D Rhino plugin is our priority now, it would make sense to target the libraries you are providing. At the very least, the WPF and Winforms variants would be needed to support our current projects. We would like the ability to expand to other platforms in the future.

Hope that clears things up a bit. Maybe you have some other ideas about how we could solve this.

Thanks for pointing me to the developer samples, they will be useful for our development.

Thanks,
Piotr

6

Hi @Piotr_Bandyk,

We have no plans to bundle Eto.WinForms within Rhino at this point, and the bundled Eto will not necessarily be the same as a released version of Eto either. On top of that, the Eto that is bundled in Rhino is strong named (with a Rhino-specific key) which basically breaks everything. However, you have a few options to make this easier to share your code:

  1. Use different build configurations and use a conditional project reference in your .csproj
  2. Use two .csproj files and link to the same source files (not ideal when you want to add or move files)
  3. Use two .csproj files and use a shared project to reference the shared source files.

I think #3 is probably your best bet as it’d give you the most flexibility without having to modify csproj files manually.

Hope this helps!
Curtis.

7

Hi Curtis,

Thanks for the ideas. We may try the third option to maintain the compatibility with Rhino and other projects.

Just thinking out loud - would it be possible for our plugin to reference a different version of Eto?

Best regards,
Piotr

8

Sorry, that would not be possible. Since the bundled Eto.dll in Rhino is strong named, you cannot reference a different Eto.dll. Basically, it will treat whatever Eto.dll you reference as a completely separate entity and you won’t get any integration with Rhino.

Hope this helps!
Curtis.