Giving Mono Souper Powers

I have a more general question: has anyone here built a truly portable app using Mono (i.e. one that runs on several platforms, has a reasonable number of active users and is supported) and can share some insights regarding performance and other issues? If you started today, would you still use Mono?

You mean like all those apps running on iOS and Android on top of Xamarin?

https://docs.microsoft.com/en-us/xamarin/cross-platform/part...

https://customers.microsoft.com/en-us/search?sq=%22Xamarin%2...

Wow that is crazy. C&C was a childhood favourite, and I'm so happy to hear it has been cloned as free software!

I can't share the name, but we've built a complete enterprise stack on Mono. There are several parts:

- Server, Nancy2/Marten/Hangfire, runs on linux

- Headless clients for linux and Windows (x64)

- GUI clients for macOS, linux and Windows (x64)

The server is deployed as a static fat binary. The headless clients are static binaries for linux and .NET proper for Windows.

The GUI clients use Eto, which in turn means:

- Static binary using Eto.Gtk on linux

- Static, signed app bundle (Gatekeeper friendly) using Eto.Xamarin on macOS

- .NET proper application using Eto.Wpf on Windows

No performance issues so far. I wish Mono would implement a GUI for the profiler though. The log profiler is great to use, but clunky in comparison with dotTrace or NProfiler.

The whole architecture sounds complicated but really isn't. It's a single solution with three* projects:

- Server

- Headless Clients

- Single Eto GUI for all platforms

- (* Target build projects for the GUI platforms, no code in here)

The build server then only needs to do some additional work for creating DMG installers and signing the macOS app.

I am the main developer on an open source app called Radarr (https://github.com/Radarr/Radarr). It focuses on automatically downloading movies and managing said movies.

While we have used mono only one „one“ platform technically (Unix), I would still like to add my own experience, since we encountered some different behaviour on macOS and Linux. Also I have spent the last week or so tracking down memory leaks for our App :)

First of all, tracking down memory leaks with mono is really not fun. The chances are very high, that the memory leak does not occur in the managed parts of either your or other people‘s code, else the garbage collector should have collected that anyways. While you do have an integrated memory profiler, it seems that they like to change them every so often and even the current one isn‘t very compatible. E.g. one user sent me a profiling report, that I could neither open via GUI nor via the commandline. Furthermore, the only GUI option available is Xamarin profiler, which does not run on Linux (more on that later). While it does the job, it likes to crash a lot and eats up a huge chunk of memory, especially if you have a large profiling snapshot.

Since I had to deal with unmanaged leaks (as indicated by the managed snapshots I collected), I tried to use valgrind. However, it seems that mono uses SIGSEGV instead of checking for null pointers beforhand and then uses signalhandlers to throw NullPointerExceptions. This would normally not be a problem, but one part of the mono System runtime is very likely to have a NullPointerException. Thus valgrind sees a SIGSEGV and mono‘s signal handler playing around with the stack. It decides that this is not acceptable and instantly termiantes the app. After I patched that out, valgrind seemed to work, except that it didn‘t find any leaks and the memory leak was not even there anymore!

So I just started randomly commenting out lines of functions that could potentially be involved and got lucky. I still haven‘t figured out why that line of code leaks memory though.

Furthemore, I also found some memory leaks inside mono‘s native HttpWebResponses.

We are still trying out figure out another memory leak that occurs and haven‘t had any luck finding out why. It‘s especially hard, since this particular memory leak only occurs on Linux. (If you want to see the full discussion I recommend you look at issues: https://github.com/Radarr/Radarr/issues/1580 and https://github.com/Radarr/Radarr/issues/3157).

On the other hand, from my experience the performance itself seems almost as good as on Windows, save for the memory leaks. Some big requests to the backend of the app might take 5-10% longer on mono, but that‘s negligble IMO.

So, in short, if you don‘t have any issues with performance it‘s good. However, as soon as you do have some issues, you will be faced with a lot of problems. There is no documentation on profiling or what could cause problems, except for a few standard things that‘s more generally .NET related. By pure luck, I found a guid that shows how you can do profiling for your mono app in Instruments, but that didn‘t help either, since the leaks only occur on Linux.

Nevertheless, we are planning on moving to .NET Core anyways, so no I would not use mono.