Is Mono a subset of .NET?

Question

I know the converse is not true, but if my application works using Mono is it guaranteed to work if I switch to the real deal? If not, where can I find a list of caveats?

Answer 1

No. Mono includes several alternative UI frameworks (Gtk#, wxWindows for .NET, etc).

If you only use Microsoft-defined classes, though, you should be fine.

Answer 2

Mono is an implementation of the CLI standard, as is the CLR.

It includes many of the libraries you would find in the .NET BCL, but not any that are windows specific (WMI is one whole domain that comes to mind).

So long as you keep to features that are not windows specific, you should be fine.

The mono team have created a tool to check if your code should work on mono - MoMA, the Mono Migration Analyzer.

As far as using mono code with the Microsoft compilers, so long as you include the libraries you are using and are not doing any pInvokes on linux, you should be fine.

Answer 3

Mono does not extend BCL APIs, at least not in the System namespace. Therefore, you can be quite certain that an application using only types from the System namespace will be portable without recompilation from Mono to .NET. Of course, you won't find anything in the Mono namespace once you're in .NET world.

From the Mono FAQ:

Do you plan to Embrace and Extend .NET?

Embracing a good technology is good. Extending technologies in incompatible ways is bad for the users, so we do not plan on making incompatible changes to the technologies.

If you have innovative ideas, and want to create new classes, we encourage you to make those classes operate correctly well in both Mono and .NET. Today Mono ships with a number of extra libraries that were developed either by members of the Mono community, or other groups. In some cases, we have found the bits from Microsoft to be incomplete, but we avoid breaking the API, instead we expose the missing functionality in new assemblies (see Mono.Security)

Answer 4

Both Mono and .NET are supersets of the ECMA/ISO CLI family of specifications. However, neither .NET nor Mono are subsets of the other. Both Mono and .NET add features on top of ECMA/ISO CLI, but while Mono implements many of .NET's additions, .NET does not implement any of Mono's additions.

Here's a few examples:

• Mono has larger arrays. This is actually not an added feature to the ECMA/ISO CLI specification but an optional one: the specification says that array indices must be either 32 bit or 64 bit. .NET chose 32 bit but Mono chose 64, since arrays with 10 billion entries and more are quite common in supercomputing applications, where Mono has quite a strong market share. So, if your app has an array with several billions of entries, it will run just fine on Mono but won't work on .NET.
• Mono has continuations built into the VM. These are important for game programming.
• Mono has native SIMD support for parallel operations on arrays, which are mapped to native CPU SIMD instructions (MMX, SSE, VMX).
• Mono has compiler-as-a-service, which Microsoft has been only vaguely talking about for some unspecified future version of .NET.
• Mono has a lot of additional libraries, especially bindings to graphics libraries other than Windows Forms (wx.NET, Gtk#, Cocoa#, ...)

Note, however, that (except for the arrays), all of these are clearly distinguishible by their namespaces, since none of them live in the System or Microsoft namespaces.

---

EDIT: Actually, most of the above-mentioned extensions are explicitly designed to also work on .NET. For example, Mono.Simd also runs on .NET, but without the runtime support that the Mono VM has, it's unusably slow. (Basically, all the SIMD operations are implemented in C#, but the Mono compiler detects those calls and replaces them with their corresponding assembly instructions. That way, they work on .NET, but without the special treatment, they are significantly slower.) Also, the C# REPL is currently being re-implemented on top of Reflection.Emit (at the moment, it calls the Mono compiler directly), so that it will work on .NET in the future. Gtk# works just fine on Windows and .NET.

Only the Mono.Tasklet library cannot be implemented on .NET, since it requires VM-level support for continuations.