DevExpress products and Mono (part 1 - WinForms)

Recently I took it upon myself to do some testing with our products and Mono. We've been asked often in the past about Mono compatibility, and given the recent release of — and excitement about — MonoTouch, the number of these questions have increased.

The first trial I did was with our WinForms controls, because I was fairly certain it would be a fairly simple conclusion and as it happened my experiment validated my guess.

First things first, though. Although Mono does have complete support for creating WinForms applications, there is a big issue in my view, especially when you consider third-party controls. Suppose you're targeting Mac OSX and by happenstance our WinForms controls work in Mono. You write a WinForms app with XtraGrid and XtraBars and the rest, deploy it, and... it just looks like a Windows app running on a Mac. It looks wrong, it doesn't fit in. You might get away with it in the corporate environment but, for the wider Mac audience, you'd be laughed out of court. Far better would be to have a set of WinForms controls that look like native Mac controls. And that, of course, we don't have (although you could get close with our McSkin I suppose ).

Onto the actual test. The Mono Project have this nifty program that analyzes your application and assemblies for possible problems when running under Mono. It's called MoMA, the Mono Migration Analyzer. I downloaded it and ran it on our big demo for XtraGrid, in the belief that I might as well go for broke. That's me all over: put it all on red.

Firstly, cool, everything we use in .NET is present in Mono and I'm particularly glad we don't have any methods that throw NotImplementedException. Obviously, we provide you with fully implemented classes in our products. That's a relief.

The second item there is the warning I was most definitely expecting: the P/Invoke problem. This particular application (and the assemblies it uses) uses 23 P/Invokes.

A reminder. A P/Invoke (Platform Invoke) is the .NET term for a routine in a native DLL that you call from within managed code. The DLL, in most cases, is part of native Windows: we don't go for writing our own native DLLs for our .NET products. Here's a couple of examples of such a routine (taken from XtraBars):

[DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true)]
public static extern IntPtr GetFocus();
[DllImport("user32.dll", CharSet = CharSet.Auto, ExactSpelling = true)]
public static extern IntPtr SetFocus(HandleRef hWnd);

Here the P/Invokes are getting references to the GetFocus() and SetFocus() routines from user32.dll, a pretty important DLL in Windows.

The issue with P/Invokes and Mono is that these native Windows system DLLs do not exist in other operating systems. Sure, other OSes are likely to have something functionally similar, but they won't be in a DLL called user32.dll, and even if they had similar names, they might have different signatures. We'll come back to this in a moment.

Let's take a look at the P/Invokes in this particular application:

I'd have to say there's nothing particularly out of the ordinary here. Most of the P/Invokes we use are out of user32.dll and deal with the keyboard and mouse.

Actually I suppose you could argue that we've got references to certain Windows routines all over the place, and that we should aggregate them into some DXNativeWindows assembly and reuse that. I won't argue, and in fact, if we were to fully support Mono, that's essentially what we would have to do. Once we'd done that, it should be then be easier to implement and provide DXNativeMacOSX and DXNativeLinux assemblies as well, for deployment on those platforms.

For interest, here's the detail for the final warning item:

Some of these might be cause for concern ("useEmbeddedColorManagement isn't supported"? Qué?), but I admit to not having done too much research on them as yet so I don't know how difficult they'd be to work around. The P/Invokes are a bigger problem to my mind.

Now we're at the end of this particular post, I'd have to say, given my results, our providing WinForms Mono support for every possible platform is going to be very low priority. Providing WinForms Mono for a specific platform (say, Mac OSX) is more of a possibility, apart from the problem I mentioned early on: Our controls were designed and implemented to look good on Windows. I'm going to guess we would have a fairly heavy-duty bit of design work to make them look good on the Mac, and that's before we factor in the work we need to do to research and implement the Mac OSX equivalents to the Windows routines we're using.

Unfortunately, given the other opportunities we have to tackle on our main platform, it's unlikely we'd be devoting resources to this project in the near to middle future. The opportunity cost is just too high at the present time.

Next time: ASP.NET.

Free DevExpress Products - Get Your Copy Today