Feedback on Porting .NET Code Base to Mac OSX

Introduction

Few years ago, after releasing the CppDepend product, many users asked us for a Mac OSX version to analyze the Objective C code base. Last year, we decided to develop XClarify, the CppDepend like for Objective C.

Our GUI was developed using .NET and porting all the code to Objective C has the big drawback to maintain two versions, time for our research and development team to make some research on how to reuse our .NET code for the Mac OSX version.

First Solution Chosen

The trivial solution was to use Mono, it wasn't an easy task, specially because we use DevExpress which does not complain with Mono due to the overuse of P/Invoke calls.

In our first version, we used the Mono Winforms implementation to avoid big changes on our code base. Notice that using Windows.Forms.dll, you will be forced to use X11. Indeed in theory, the mono Windows Forms library works without X11, but if you do so, the application became unusable, and quickly you will execute Mono by exporting the MONO_MWF_MAC_FORCE_X11 variable. to force the uses of X11, and in this case XQuartz must be installed,

Another big issue when using X11 is that only Mono <=2.10.5 works as expected, and unfortunately for all the new mono versions, the windows.forms library is not the priority and it's not maintained anymore.

After resolving all the technical issues, we released a beta version. We contacted some Objective C developers to give XClarify a try, we discovered our big mistake, and here is some feedback from Mac OSX users:

Having an application that looks like Visual Studio on OS X is enough of an insult.

I've downloaded your product for the trial but when I'm trying to run it, it is asking for X11. I've read a couple of things online which say that installing this X11 over Apples could cause instabilities - what are the risks in doing this and why is it needed?

Thanks to beta users, we were warned about the biggest mistake we have made and it is time for us to quickly find another solution to correct this, so how to make a product that meets the Mac OSX users requirements?

Second Solution Chosen

The better solution to have a native Mac OSX look & feel is to use the cocoa framework, and fortunately a cocoa porting to Mono is provided by Xamarin which offers the MonoMac library, however using MonoMac will impact all the GUI code base, and we can't have any more than one code base to maintain. But we learned well the lesson:

What's more important is not to have one code base to maintain but what the user is waiting for when he uses the product.

We decided for our second version to use MonoMac and remove all the dependencies with System.Windows.Forms and System.Drawing libraries to use Cocoa instead.

Concerning removing the dependency with System.Drawing, there's this library, but it's not mature yet, and some blocking bugs will encourage you to not use it.

To make the porting easier, we needed a good GUI library which would simplify the GUI development, and we found a powerful library, named Eto. Its development team is very active and the library is stable. After releasing our second version, we had to package the product to a standalone application which must be easy to install without installing other requirements.

The MonoMac library is not sufficient for that and you have to use Xam.Mac which is not free.

Conclusion

In conclusion, if you want to port your .NET application to Mac OSX, an interesting solution is to use Xamarin Studio, Xam.Mac and Eto libraries, and especially avoid using System.Windows.forms and System.Drawing.