How do I make sure that the c# plugins I develop work on both mac and PC?
I assume that certain libraries might not work on both mac and PC. For example, when I use Microsoft’s System namespace, will this work on Mac? Maybe I just have to change what is packaged in the .gha file upon build.
I found this page about cross platform development. I also found documentation for the differences in the distribution. Here are the pages about the different IDE’s for Mac and PC. However, I still don’t have an acute understanding of which namespaces will work in both. It seems that even the RhinoCommon.dll is different for the two platforms.
As far as I can tell, I might have to develop the plugin on a Mac computer. There isn’t that much information out there, and the most recent post I can find on the topic is from 2015. I’m really hoping I can develop the plugin just within Visual Studio for Windows in a way that it will work for both platforms.
Hi,
From my personal experience: Pure C# plugins work without changes on both systems.
(I only had problems when casting types within parameters. I don’t even remember what it was but Mono (mac) was a bit different then MS .Net. I think that in most cases you don’t need this feature.)
What about when using Windows libraries in the code? I’m sure those namespaces would have to change.
For example, I want to read an external file, so I write: System.IO.File.ReadAllLines();
I image this will have to change for Mac.
Because most modern operating system are basically a big GUI application, and they do many things very different. A WPF application originates on Win32 and DirectX. This is why you will never make it run on a macOS. Even when using Eto or another Cross-Platform GUI framework (translating WPF to Cocoa and vice versa), you will never get 100 % of the same behavior.
If you are not able to test a plugin on a specific OS, then I would simply not officially support this OS.
As a rule of thumb, whenever you access something from the operating system (such as a window, a file, some other thread, etc…), you are always risking different behavior, even within a multiplatform framework which may orchestrates this for you.
This also means, as long as you are only creating and modifying shapes within a custom component, chances are very high to create a cross-platform plugin without any extra effort. This is also why many plugins work on both systems
Well, I’m aware of the technical difficulties. Nevertheless, I am surprised that there is no simple solution (for casual coders) because it is such an old problem. But never mind, offtopic…
It’s not off-topic. Foremost, there are many good technologies to support cross-platform development. But usually you trade off performance, simplicity and fewer testing, against reaching more users or the need for developing things twice. But an operating system is very complex, and you cannot guarantee that code always work the same. This is why you should test on all supported systems before releasing something. And I don’t know if its worth the effort for a casual coder to do this. This is why I would pick one platform and stick to it.
E.g. there are solutions like QT, React Native, Electron, Swing, MAUI etc…
Make sure you are not using backward slashes \ for file paths. Either use only forward slashes or use Path.Combine().
Don’t hardcode any full paths. If you need to access common system folders use the Environment.SpecialFolder enum.
But note that some of these enums might not always work on the same OS for all users. I had situations where I couldn’t get the Local App folder on some Windows machines, although the folder was present. It just returned an empty string. It is always good practice to test-paths as much possible and to think about a fallback solution. Any extra OS just increases these problems by a magnitude.
@Ryan_Daley, as Dale pointed out use Eto for cross platform user interface development on Rhino. A majority of Rhino 8’s and Grasshopper 2 user interface has been rewritten to be based on Eto.
The only commonly used libraries that you should stay away from for development are WinForms and WPF.
I do not think that this is a big deal. From my experience other frameworks like Qt or Electron are doing this job also very well by wrapping the system API. I am just wondering why there is no modern build-in solution within .NET for building cross-platform GUIs in 2022. They started with WinForms which was pretty similar to the VB6 Forms. Then they anounced Silverlight, WPF, UWP, Xamarin, Cordova, MAUI… most of them are dead and todays best solution seems to be a third-party tool which is again very similar to VB6. And dont get me wrong: Eto might be very powerfull. But after working a lot with HTML/JS/React/Canvas it doesn’t seems to be state-of-the-art. Anyway: Personal flavor and offtopic as is far away from the initial question…
@dale , I was not aware of Eto, this is the research path I needed to head down. Thank you for brining this to my attention. Eto actually seems quite powerful and flexible with the ability to do much of the same functionality found in WPF or WinForms.
There are always platform specific issues when developing for multiple operating systems; it doesn’t matter what toolkit you use. We find them and we fix them.