Debugging/diagnostics developing for Mac

Hi all,
I’ve been having a hard time debugging a plugin for Rhino for Mac (5), particularly on the Eto side. The issues are primarily around:

  • Older Eto version
  • Older Mono version
  • Managing referenced assemblies (due to Mono version)

While I can work around all of these things, I don’t seem to get any exception breaks or stack traces when something goes wrong - it just quietly doesn’t work. Have I set up my debugging configuration wrong?

An example of this would be porting a Rhino 6 compatible plugin that used a NumericStepper. The UI is all contained in an isolated dll, and tests and runs fine in a test (non-rhino) environment with nuget packages for Eto.

When building for Rhino for Mac (5), it builds fine, and runs, but the Rhino Panel loads as blank. No exceptions or diagnostics - and hence I’ve then gone through the code in a slow binary search of commenting out bits and pieces and printing ‘progress’ to system.diagnostics to attempt to figure out when it crashes. The same applies to debugging the mono environment.

My fault, of course, for referencing a higher version of Eto but I would have loved to be able to find the issue more easily.

On the mono version side - there seem to be some more recent additions to the framework that aren’t implemented - for example all the functions in System.Net.NetworkInformation throw NotImplementedException, though now appear to be fully implemented. (

So the questions are:

  • Is there a better way of getting diagnostic information? I tried dtruss but didn’t find any relevant output.
  • Will Rhino 6 for Mac use a newer Mono version?
  • And similarly will it use a newer Eto version?

I’ll look through the WIP shortly but wanted to raise the debugging issue first and see if I’m missing something.


PS - On the other hand, when it does work, having a cross platform plugin UI is fantastic!

Hey Cam-

Ugh. Sorry you are hitting these issues. Let’s start with a couple questions, mostly so we can be on the same page as we try to work through this…

  1. What version of Visual Studio for Mac are you using?
  2. What version of the RhinoCommonXamarinStudioAddin are you running?

This is not terribly surprising…

  • Will Rhino 6 for Mac use a newer Mono version?
  • And similarly will it use a newer Eto version?

Yes and yes.

In Rhino 5 for Mac (5.5.3) we are embedding ancient Mono: 4.0.2 (we will not be updating that embedded mono version)

In Rhino 6 for Mac (latest BETA) we are embedding Mono (and we plan to update periodically as new versions become available and we can test them). In V6, you can run TestMonoVersion to figure out what is there.

So I’m not shocked that you might try to call a newer API that might not be in 4.0.2. (I admit I have not checked your particular example… yet). Just a caution too: I’ve run into situations where calling the same API (even those that are supported) in older versions where you get “different” results.

We may be able to work around your issues, perhaps with a cloned .csproj approach where you support V5 (or perhaps creative defines).

Finally, a non-technical concern: How badly do you want to support Rhino 5 for Mac? I want to do everything we can to help with this, but just keep in mind that we are very close to shipping our initial commercial version of Rhino 6 for Mac (we are done with WIPs, we’re feature-complete and are in Beta now). Just food for thought.

@curtisw might have other insights too.

Hey @dan,
Thanks for getting back to me quickly.


I’m happy to use platform defines and limit some of the features on Rhino 5 for Mac - my issue is just about finding exactly where they need to be based on what features are or aren’t available. It’s tricky to debug due to the UI and backend (non-rhino) libraries all functioning correctly when running in a standalone Eto.Mac/64 app. A little tricker still when trying to test with old versions of Eto as they have to be in a bundle test.

As far as version support goes, there’s a cost-benefit analysis here of course. I’d like to support a limited feature set on Rhino 5 for Mac, but have the full integration on 6. Though if it’s too difficult then it’ll just be 6.

I’m hoping that the Mono upgrade in 6 will also fix some miscellaneous issues I’m having with 3rd partly libraries. For example NLog works correctly, but if I procedurally create a filetarget it silently crashes. Again, doesn’t happen in a standalone app, so I can only assume it’s mono-related. Similarly I have no idea why creating an ObservableCollection<> doesn’t work. And if a dll is missing there’s also a silent crash with no diagnostics.

To provide some more feedback while this is all fresh: (note that I am coming from a background in .net/win development but have comparatively little mac development experience so they may be a little naive)

  1. It appears that in the Rhino Xamarin Studio Addin if I explicitly select ‘Library’ in the Rhino options, it still wraps into a .gha if Grasshopper is referenced. This is a little annoying because I’m building a .dll which references Grasshopper but isn’t otherwise a regular grasshopper plugin. A post-postbuild script should solve this but I’d say it’s unexpected behaviour. Similarly:

  2. It was/is little confusing was being unable to locate the post-build scripts or conditions that are being used both for renaming or controlling are which files are copied/loaded. On the VS/Win side it’s straightforward to see/edit the post build script, launch parameters of Rhino, etc. On the Mac side, I wanted to change some of these things but wasn’t able to find them in the traditional build event targets (on the GUI side, admittedly I haven’t looked through the .csproj). Are there any files other than the .csproj I can look at to find these?

  3. In the aforementioned Grasshopper-referencing library, I was subscribing to a Canvas event that produced a windows forms related component.This throws a compiler error, to be expected. Is there a way to handle this? I don’t need the component, just the event. Note I was referencing the 0.9.76 nuget package in this case.

  4. I haven’t been able to figure out is why I can use C# 7 in the visual studio editor, but when I compile it seems to attempt with <= 6 - some features such as pattern matching don’t seem to be available. Any advice would be welcome. My current intention is to sort out the framework issues and then produce the .macrhi and .rhi with post build events from the Windows side.

  5. Is there any disadvantage to targeting higher .net framework versions? On Windows I understand this just requires the user to have installed the framework, but I’m not familiar with the impact when going through Mono. Our minimum would be 4.6.1 (which appears to function correctly) and ideal would be 4.7.2 as this is advised by Microsoft for better .netstandard 2.0 compatibility.

  6. I’m not familiar with how references are being resolved on the Mono/RhinoMac side, but is there any disadvantage to using ILMerge/ILRepack to bundle assemblies? It seems to work correctly thus far, I just thought I’d check…

One thing I miss from Windows, though I assume it’s a pipe dream, is the simplicity of ‘Attach a Process’ and picking Rhino, even if there’s no debugging session active…

Of course a lot of this is just learning curve :] Not intending to be negative, just sharing my experience with jumping across platforms. And apologies for the wall of text.


Hi Cam-

There is a lot to dig into here and I feel like I could be much more helpful if I could see a test-harness project that illustrates some of these problems. Without that, I’m kind of flailing making guesses as to what you are experiencing and probably missing some important details.

The RhinoCommon Xamarin Studio Extension is a crutch, but you don’t have to use it. You can always great a project from non-boilerplate templates and Reference what you need. As always, you can edit the .csproj manually in your favorite editor and point the references to Applications/ … you get the idea.

I’m a little confused. You should be able to right-click or double-click on any .csproj in the solution and navigate to Custom Commands …or are you referring to something different? By the same token, in the Project settings, there is a Run section as well for launch arguments.

It is critical to understand that we are embedding Mono in the bundle. This means you are calling through Mono code that WE ship; not that which may or may not be installed in /Library/Frameworks/Mono.Framework. This is a crucial difference between how .NET is managed in Windows and on Mac.

I don’t know the answer to this one.

I’d like to be clear that I think what you are attempting to do - support Rhino 6 for Windows, Rhino 6 for Mac, and Rhino 5 for Mac from the same solution is challenging and not something we make easy on you as you have discovered.

Please feel free to create a test-harness project with some dummy stuff that illustrates and send us a link to the repo. It will likely give us a much better idea than a text description. At least then we will both be looking at the same thing.


@stevebaer and @curtisw, I just wanted to make sure you are watching this topic. I think there are some potential pain-points here that we can be aware of and it might lead to better tooling or documentation.

Hey @dan,
Thanks for getting back to me on all those points, very helpful.

Regarding the post build events / custom commands. When I start up the default template (v5), I get this configuration (correct):

But I don’t get anything showing up in the Custom Commands: After Build:

The .csproj looks like this:

So I can’t see anything that would trigger the post build event which renames the build folder to .rhp, but it does.

By this, all I mean is that the behaviour on VS/Win is that using the Rhino VS extension configures the post build for you, and you’re free to change it after that - but I don’t seem to be able to do that on Mac as I can’t see the post build target that renames the .rhp in either the custom commands or the .csproj. Not a big deal, because as you say I can configure these myself, but just flagging as an unexpected behaviour when switching to Mac and using the VS addin.

This is really useful to know, thankyou! For us it means we can’t rely on higher versions and require users to download, as we would on the Windows side.

As far as ILMerge/Repack goes, it seems to be working as expected so far which is great.

And lastly, I finally got around to testing with Rhino 6 for Mac (WIP) and everything works as expected for the most part, so likely for us this is a much easier route as we can build the .macrhi at the same time we build the .rhi on the Windows side.