Is Rhino v6 still sufficient to start learning C# and WPF?
Are you asking about learning C# and WPF for Rhino development？
Why not use current Rhino instead?
if you want to learn modern c# / .net features, use the latest Version.
See also
Now we use rhino to code…
If Rhino can just cook and clean i swear this amazing multi sided tool can do it all.
Rhino… do my taxes!
Short answer is no, you should start with Rhino 8, which involves some major changes to the base Framework and how scripts work. Starting with R6 would slow you down a lot because it suffered from limitations which do not exist anymore in R8.
So, my question was about the Rhino v6 (not the latest version).
Yes, so my question is if I can use WPF UI in Rhino v6 plug-ins. I could invest my time (1-2 years) to learn WPF and convert my Python scripts into plug-ins.
Since you already have a Python background, why not use Eto? Rhino 6 supports Eto for plug-ins, Grasshopper components, and Python scripts, so it may be a better fit than learning WPF. That said, learning WPF is still a perfectly valid option.
You can use ETO to create user interfaces with Python in Rhino 6, which will be cross platform, rather than windows only WPF.
Rhino 6 also ships with the Rhino Script Compiler that allows you to package your Python scripts into Rhino plugins.
Cheers
DK
Hi @onrender,
Can you use WPF in a Rhino 6 plug-in? Yes. On Windows, a Rhino panel can be a WinForms control, a WPF FrameworkElement, or an Eto control — Rhino hosts the WPF element for you. Modal and modeless WPF windows work too; you just set the Rhino main window as the owner. That’s been true since Rhino 6 shipped. So nothing about V6 blocks you from learning WPF.
Should you spend 1–2 years learning it there? That’s where I’d push back, and I think it’s what the other replies were reaching for.
Rhino 6 shipped in 2018 — it’s eight years old. Add the one to two years you’re planning to invest, and you’d be finishing up on a platform that’s a decade old. That shows up in concrete ways:
- Rhino 6 and 7 plug-ins run on .NET Framework 4.x. Rhino 8 defaults to .NET 8, and Rhino 9 defaults to .NET 10. Framework plug-ins still load in 9, but that runtime is formally deprecated — it isn’t guaranteed to stay available.
- The C# language matters more than the Rhino version here. .NET Framework caps you around C# 7.3, which is from 2018 as well. Nearly every tutorial, book, and Stack Overflow answer you’ll hit while learning assumes modern C# — records, pattern matching, nullable reference types, modern async. On V6 you’d spend a lot of time discovering that the example you just found doesn’t compile. That’s a rough way to learn a language.
- Current project templates and documentation target Rhino 8+. Building for V6 today means going off the paved road for setup.
On WPF vs Eto specifically. WPF is not dead — it runs on .NET on Windows and is fully usable in Rhino 8 and 9. But two things are worth knowing before you commit a year or two to it.
First, WPF is Windows-only. It does not run on macOS at all — not in a degraded form, it simply isn’t there. If you ever want your plug-in on Mac Rhino, you don’t port the UI, you rewrite it from scratch in something else. Eto exists precisely to avoid that: you write the UI once and it runs on both. Whether that matters depends entirely on whether Mac is ever in your plans — if it truly isn’t, this is a non-issue.
Second, while WPF works in panels, we don’t use WPF ourselves. Rhino’s own UI is largely written in Eto, and it’s matured a great deal since Rhino 6, where it was still quite new. That means the help you can expect here for WPF-specific questions is limited — we can get you as far as hosting your control in Rhino, but past that you’d be relying on the general WPF community. If you’re learning from scratch and expect to ask questions along the way, that’s a real argument for Eto on Rhino 8/9.
One more thing, since you mentioned Python. You may not need 1–2 years of C# to get where you’re going. Rhino 6 already ships the Rhino Script Compiler — it’s on your machine right now — and it packages Python scripts into Rhino plug-ins. Rhino 8 goes further with a new script editor, Python 3 with pip packages, and compiling scripts into plug-ins and Grasshopper components with Eto UI. But if the actual goal is “turn my scripts into something I can distribute,” the V6 you already have will do that today, without learning a new language or a new UI framework first.
So, where that leaves you. V6 won’t stop you from learning WPF — the capability is genuinely there. My concern isn’t Rhino, it’s the learning experience: eight-year-old C#, examples that won’t compile, and setup off the documented path. If you can work in Rhino 8 or 9, learn there. If V6 is what you’ve got, you’re still not stuck — the Script Compiler path above costs you nothing and starts today. And if you just want to see what modern C# and .NET look like in Rhino before deciding anything, the evaluation is free for 90 days.
Holler if you have any question or concerns.
– Dale
Thanks Dale!
1. Back to 2018 - that time ETO was not available with C# (as far as I know).
2. Also, it was not dockable.
3.That time the Python Plug-in converter did not handle more than just one python script file. Can I convert multiple python script files into one plug-in with v8?
So, I can go with v8 and ETO if it is dockable, can be embedded into C# plug-in.
I was thinking on WPF because If I learn it, I could write desktop applications later. Qt with Python could also be an option. I can use ETO as well for desktop apps. I am not sure which one is the best option.
4. Can I insert image in ETO?
5. Is there TreeGridView in ETO?
Hi @onrender,
1. Eto with C# in 2018. It was there — Eto is a plain .NET library, never Python-only. What was thin was the docs and samples, which were mostly Python. That’s reversed now.
2. Dockable. Eto panels have been dockable since before Rhino 6 shipped. You register your Eto control with Rhino’s panel system and it docks, floats and tabs like any other panel — hosted in a C# plug-in is the normal arrangement, not a workaround.
3. Multiple Python files in one plug-in. Yes, in Rhino 8. Script projects hold multiple commands and build a .rhp (or a .gha for Grasshopper). The one-file limit you remember is gone.
4. Images in Eto. Yes — ImageView for a plain image, Drawable for a custom-painted surface. Images work in grid cells too.
5. TreeGridView. Yes, and you use it daily without knowing: the Layers panel is an Eto TreeGridView. So is the Layouts panel.
Eto guides: Rhino - Eto Guides
Samples: GitHub - mcneel/rhino-developer-samples: Rhino and Grasshopper developer sample code · GitHub
– Dale
Just one note - dockable UIs are only available directly from C#. I have worked around this by creating a very simple C# plugin that provides the dockable UI container, and then populating it from my Python code.
Honestly, this is the only Eto/UI limitation or difference I’ve found between a Rhino plugin written in C# and one written in Python. Everything else works essentially the same across the two platforms.
Cheers,
DK
I have created multiple applications in WPF using C#. Later I migrated most applications to Avalonia. Avalonia is probably the best cross-platform Desktop UI library for NET. However, WPF and Avalonia have a very steep learning curve. Especially when using the MVVM pattern.
When you master it, there is almost nothing better. The only library, which is as good or even better as Avalonia, in CPython, is QT (which has a weird licensing model). Eto is a niché library, with limited usage outside of Rhino.
In general, you can host any UI framework in Rhino, unless you ship the dependencies and perform the interop for yourself. But its feasible and not as hard as you might believe.
I’m not promoting to do this, unless you know exactly what you are doing. Probably you should stick with Eto. But its doable