Pages

Thursday, April 28, 2005

Mono FAQs



































Mono Platforms


What operating systems does Mono run on?


Mono is known to run on Linux, UNIX and Windows systems.


Can I run Mono applications without using 'mono program.exe'?


Yes, this is possible on Linux systems, to do this, use something like:


if [ ! -e /proc/sys/fs/binfmt_misc/register ]; then
/sbin/modprobe binfmt_misc mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
fi
if [ -e /proc/sys/fs/binfmt_misc/register ]; then
echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register
else
echo "No binfmt_misc support" exit 1
fi

What architectures does Mono support?


Mono today ships with a Just-in-Time compiler for x86, PowerPC, S390 and SPARC-based systems. It is tested regularly on Linux, FreeBSD and Windows (with the XP/NT core).
There is also an interpreter, which is slower that runs on the x86, s390, SPARC, HPPA, StrongARM and PowerPC architectures.


Can Mono run on Windows 9x, or ME editions?


Mono requires Unicode versions of Win32 APIs to run, and only a handful of the
"W" functions is supported under Win9x.
There is Microsoft Layer for Unicode that provides implementation of these APIs on 9x systems.

Unfortunately it uses linker trick for delayed load that is not supported by ld, so some sort of adapter is necessary. You will need MSLU and one of the following libs to link Mono to unicows.dll http://mono.eurosoft.od.ua/files/unimono.zip (http://mono.eurosoft.od.ua/files/unimono.zip) or alternatively search the net for "libunicows".

No changes to the Mono source code are required, the only thing is to make sure that linker will resolve imports to adapter library instead of Win32 libs. This is achieved by inserting -lunimono before -lkerner32/user32 in the linker's specs file.


Why support Windows, when you can run the real thing?


There are various reasons:


  • About half the contributors to Mono are Windows developers. They have many different reasons for contributing to the effort, and we find it very important to let those developers run the runtime on Windows without forcing them to use a new operating system.

  • Supporting Windows helps us identify the portable portions of Mono from the non-portable versions of it, helping Mono become more portable in the future.

  • Mono does not heavily modify the windows registry, update system DLLs, install DLLs to the Windows/System32 path. In other words, I knew Mono would not cause any legacy enterprise applications to stop working - and it hasn't. However, our CIO is againt it because of the changes that would be made to Windows 2000, such as, affecting security.

Compatibility


Can Mono run applications developed with the Microsoft.NET framework?


Yes, Mono can run applications developed with the Microsoft .NET Framework on UNIX. There are a few caveats to keep in mind: Mono has not been completed yet, so a few API calls might be missing; And in some cases the Mono behavior might be incorrect.


Will missing API entry points be implemented?


Yes, the goal of Mono is to implement precisely the .NET Framework API (as well as compile-time selectable subsets, for those interested in a lighter version of Mono).


If the behavior of an API call is different, will you fix it?


Yes, we will. But we will need your assistance for this. If you find a bug in the Mono implementation, please fill a bug report in http://bugzilla.ximian.com (http://bugzilla.ximian.com). Do not assume we know about the problem, we might not, and using the bug tracking system helps us organize the development process.


Can I develop my applications on Windows, and deploy on a supported Mono platform (like Linux)?


Yes, you can.
As of today, Mono is not 100% finished, so it is sometimes useful to compile the code with Mono, to find out if your application depends on unimplemented functionality.


Will applications run out the box with Mono?


Sometimes they will. But sometimes a .NET application might invoke Win32 API calls, or assume certain patterns that are not correct for cross-platform applications.


What is a 100% .NET application?


A '100% .NET application' is one that only uses the APIs defined under the System namespace and does not use P/Invoke. These applications would in theory run unmodified on Windows, Linux, HP-UX, Solaris, MacOS X and others.
Note that this requirement also holds for all assemblies used by the application. If one of them is Windows-specific, then the entire program is not a 100% .NET application.
Furthermore, a 100% .NET application must not contain non-standard data streams in the assembly. For example, Visual Studio .NET will insert a #- stream into assemblies built under the "Debug" target. This stream contains debugging information for use by Visual Studio .NET; however, this stream can not be interpreted by Mono (unless you're willing to donate support).
Thus, it is recommended that all Visual Studio .NET-compiled code be compiled under the Release target before it is executed under Mono.


Can I execute my Visual Studio .NET program (Visual Basic .NET, Visual C#, Managed Extensions for C++, etc.) under Mono?


Yes, with some reservations.
The .NET program must either be a 100% .NET application, or (somehow) have all dependent assemblies available on all desired platforms. (How to do so is outside the bounds of this FAQ.)
Mono must also have an implementation for the .NET assemblies used. For example the System.EnterpriseServices namespace is part of .NET, but it has not been implemented in Mono. Thus, any applications using this namespace will not run under Mono.
With regards to languages, C# applications tend to be most portable.
Visual Basic .NET applications are portable, but Mono's Microsoft.VisualBasic.dll implementation is incomplete. It is recommended to either avoid using this assembly in your own code, only use the portions that Mono has implemented, or to help implement the missing features. Additionally, you can set 'Option Strict On', which eliminates the implicit calls to the unimplemented Microsoft.VisualBasic.CompilerServices.ObjectType class. (Thanks to Jörg Rosenkranz.)
Managed Extensions for C++ is least likely to operate under Mono. Mono does not support mixed mode assemblies (that is, assemblies containing both managed and unmanaged code, which Managed C++ can produce). You need a fully-managed assembly to run under Mono, and getting the Visual C++ .NET compiler to generate such an executable can be difficult. You need to use only the .NET-framework assemblies, not the C libraries (you can't use printf(3) for example.), and you need to use the linker options /nodefaultlib /entry:main mscoree.lib in addition to the /clr compiler flag. You can still use certain compiler intrinsic functions (such as memcpy(3)) and the STL. You should also see
Converting Managed Extensions for C++ Projects from Mixed Mode to Pure Intermediate Language (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcgrfconvertingmanagedextensionsforcprojectsfrommixed-modetopureil.asp) at MSDN. Finally, you can use PEVERIFY.EXE from the .NET SDK to determine if the assembly is fully managed.

Thanks to Serge Chaban for the linker flags to use.


Does Mono have a Global Assembly Cache (GAC)?


Yes, Mono has a Global Assembly Cache.

It operates in a similar way to the .NET Global Assembly Cache, but has a few extensions, see the Assemblies_and_the_GAC article for details.


Web Services


How is Mono related to Web Services?


Mono is only related to Web Services in that it will implement the same set of classes that have been authored in the .NET Framework to simplify and streamline the process of building Web Services.

But most importantly, Mono is an Open Source implementation of the .NET Framework.


Can I author Web Services with Mono?


You will be able to write Web Services on .NET that run on Mono and vice-versa.


If Mono implements the SDK classes, will I be able to write and execute .NET Web Services with it?


Yes. When the project is finished, you will be able to use the same technologies that are available through the .NET Framework SDK on Windows to write Web Services.


What about Soup? Can I use Soup without Mono?


Soup is a library for GNOME applications to create SOAP servers and SOAP clients, and can be used without Mono. You can browse the source code for soup using GNOME's Bonsai (http://cvs.gnome.org/bonsai/).


Can I use CORBA?


Yes. The CLI contains enough information about a class that exposing it to other RPC systems (like CORBA) is really simple, and does not even require support from an object.

Remoting.CORBA (http://remoting-corba.sourceforge.net/) is a CORBA implementation that is gaining momentum.
Building an implementation of the Bonobo interfaces once this is ready should be relatively simple.

There are other CORBA implementations for .NET available as well.


Can I serialize my objects to other things other than XML?


Yes. We support runtime serialization as well as XML serialization.


Will Mono use ORBit?


There are a few advantages in using ORBit, like reusing existing code and leveraging all the work done on it. Michael Meeks has posted a few reasons (http://lists.ximian.com/archives/public/mono-list/2002-September/008592.html), as well as some ideas (http://lists.ximian.com/archives/public/mono-list/2002-September/008657.html) that could be used to reuse ORBit.

Most users are likely to choose a native .NET solution, like Remoting.CORBA (http://cvs.gnome.org/bonsai)


MonoDoc


What is MonoDoc?


MonoDoc is a graphical documentation browser for the Mono documentation: class libraries, tutorials and manual pages. Currently, monodoc has a GUI front-end written in Gtk# and a Web front-end using ASP.NET

The contents of Monodoc today are visible on the web here (http://www.go-mono.com/docs/)

More information about the Mono documentation can be found on the Class Library Documentation page.


Development Tools and Issues


Will it be possible to use the CLI features without using byte codes or the JIT?


Yes. The CLI engine will be made available as a shared library. The garbage collection engine, the threading abstraction, the object system, the dynamic type code system and the JIT are available for C developers to integrate with their applications if they wish to do so.


Will you have new development tools?


With any luck, Free Software enthusiasts will contribute tools to improve the developer environment. These tools could be developed initially using the Microsoft implementation of the CLI and then executed later with Mono.
We are recommending people to use and contribute to existing projects like SharpDevelop, Anjuta and Eclipse.


What kind of rules make the Common Intermediate Language useful for JITers?


The main rule is that the stack in the CLI is not a general purpose stack. You are not allowed to use it for other purposes than computing values and passing arguments to functions or return values.
At any given call or return instruction, the types on the stack have to be the same independently of the flow of execution of your code.


Is it true that the CIL is ideal for JITing and not efficient for interpreters?


The CIL is better suited to be JITed than JVM byte codes, but you can interpret them as trivially as you can interpret JVM byte codes.


Isn't it a little bit confusing to have the name of "XSP" (the same as in the Apache Project) for the ASP.NET support in Mono?


.
In Mono, xsp is just the name of the C# code generator for ASP.NET pages. In the Apache Project, it is a term for the "eXtensible Server Pages" technology so as they are very different things, they don't conflict.


Are there any plan to develop an aspx server for Mono?


.
The XSP reference server is available and you can also use mod_mono with Apache.


Is there any way I can develop the class libraries using Linux yet?


Yes. Mono has been self hosting since May 2002.


Is there any way I can install a known working copy of mono in /usr, and an experimental copy somewhere else, and have both copies use their own libraries?


Yes. Just use two installation prefixes.


How should I write tests or a tests suite?


If you do a test suite for C#, you might want to keep it independent of the Mono C# compiler, so that other compiler implementations can later use it.


Would it be too terrible to have another corlib signed as mscorlib?


We rename corlib to mscorlib also when saving the PE files, in fact, the runtime can execute program created by mono just fine.


Is it possible to build a C# file to some sort of intermediate format which can linked into a final module, like the traditional .c -> .o -> .so path?


You can use:



mcs /target:library file1.cs, mcs /target:library file2.cs,
mcs /target:exe file1.dll file2.dll /out:mybin.exe

Is there any plans for implementing remoting in the near future?


The remoting infrastructure is in place. We have implementations of the TcpChannel, HttpChannel and the Soap and Binary Formatters. They are compatible with .NET.

However, some classes from the library may have a different binary representation, because they may have a different internal data structure, so for example you won't be able to exchange a Hastable object between Mono and MS.NET. It should not be a problem if you are using primitive types, arrays or your own classes. If you have problems, please post a test case.


My C code uses the __stdcall which is not availble on Linux, how can I make the code portable Windows/UNIX across platforms?


Replace the __stdcall attribute with the STDCALL macro, and include this in your C code for newer gcc versions:

#ifndef STDCALL
#define STDCALL __attribute__((stdcall))
#endif

I want to be able to execute Mono binaries, without having to use the "mono" command. How can I do this?


From Carlos Perelló:

I think that the best solution is the binfmt feature with the wrapper that exists with Debian packages at:
http://www.debianplanet.org/mono/dists/unstable/main/source/admin/ (http://www.debianplanet.org/mono/dists/unstable/main/source/admin/)

If you want use it with Big endian machines, you should apply a patch (
http://carlos.pemas.net/debian/mono/binfmt-detector-cli.c.diff (http://carlos.pemas.net/debian/mono/binfmt-detector-cli.c.diff))

It works really good and lets you use wine also, it reads the .exe file headers and check if it's a .net executable.

This way you just execute: ./my-cool-mono-application.exe and it works without the need of any wrapper.


I see funny characters when I run programs, what is the problem?


(From Peter Williams and Gonzalo Paniagua):


This is Red Hat 9 (probably) using UTF8 on its console; the bytes are the UTF8 endianness markers. You can do:

LC_ALL=C mono myexe.exe

And they wont show up.


Alternatively, you can do:

$ echo -e "\033%G"

to enable UTF-8 on the console.


Mono and ASP.NET


Does Mono support ASP.NET?


Yes.
Mono supports ASP.NET, we have shown an unmodified IBuySpy installation running on Mono as well as various other programs. You can try it yourself downloading the XSP server.


Do I need install cygwin to work on ASP.NET in mono or Linux is enough since it is self host right now?


Linux is enough.


How can I run ASP.NET-based applications with Mono?


You need the Mono runtime and use either mod_mono or the xsp server (all available from our download page)


Any plan to make ASP.NET in mono works with Apache in Linux?


The mono project ships an Apache module named mod_mono that hosts the ASP.NET runtime.


Will you support Apache 1?


Yes, the mod_mono module works on both major versions of Apache (1.x and 2.x)


Can I run Apache 1 and Apache 2 on the same machine?


You can always keep a copy of Apache 2 running in parallel with your Apache 1.3 (either different port or using a reverse proxy).
You can also bind the two servers to different IP addresses on the same physical machine.


Mono and ADO.NET


What is the status of ADO.NET support?. Could I start migrating applications from MS.NET to Mono?


The ADO.NET support is fairly complete and there are many database providers available.


In developing the data architecture for the application are there and objects I should stay away from in order to insure the smoothest possible transition (minimum code rewrite) to Mono's ADO.NET implementation? (For example, strongly typed datasets versus untyped datasets, etc...)


We are implementing all the classes in Microsoft .NET's System.Data, so you can be sure that things will work the same in Mono as with the Microsoft implementation. There is strongly typed dataset support in Mono now.


Can you connect to a Sybase database using Mono?


Yes. use Mono.Data.SybaseClient. First of all you have to create a SybaseConnection, and then, from it, use it as any other IDbConnection-based class. See here (http://www.mono-project.com/Sybase) for more info.


Has the MySQL Connector/Net replaced ByteFX.Data


Yes it has. MySQL Connector/Net is made by MySQL AB and are the best people who would know how to access their databases. The author of ByteFX.Data no longer develops ByteFX.Data because he is employed by MySQL AB now. See here (http://www.mono-project.com/MySQL) for more info.


How do I connect to a SQL Lite database?


Use Mono.Data.SqliteClient. Make sure you are using at least Mono 1.1.4 since SQL Lite provider does not work in the Mono 1.0.x releases and prior. Use a connection string like "URI=file:SqliteTest.db" if you are using SQL Lite version 2.x or use "version=3,URI=file:SqliteTest.db" if using SQL Lite version 3.x. See here (http://www.mono-project.com/SQL_Lite) for more info.


What provider do I use to connect to PostgreSQL?


You would use Npgsql which is included with Mono. It is also included with the Win32 installer for PostgreSQL 8.0 which runs natively on Windows. See here (http://www.mono-project.com/PostgreSQL) for more info.


Mono and Java


Why don't you use Java?


After all, there are many languages that target the Java VM.

You can get very good tools for doing Java development on free systems right now. Red Hat (http://www.redhat.com) has contributed a GCC (http://gcc.gnu.org) front-end for Java (http://gcc.gnu.org/java/) that can take Java sources or Java byte codes and generate native executables; Transvirtual implemented Kaffe (http://www.kaffe.org) a JIT engine for Java; Intel also has a Java VM called ORP (http://www.intel.com/research/mrl/orp/).

The JVM is not designed to be a general purpose virtual machine. The Common Intermediate Language (CIL), on the other hand, is designed to be a target for a wide variety of programming languages, and has a set of rules designed to be optimal for JITers.


Could Java target the CLI?


Yes, Java could target the CLI, Microsoft's J# compiler does that.
The
IKVM (http://www.ikvm.net/) project builds a Java runtime that works on top of .NET and on top of Mono. IKVM is essentially a JIT compiler that translates from JVM bytecodes into CIL instructions, and then lets the native JIT engine take over.


Is it possible to write a JVM byte code to CIL converter?


Yes, this is what IKVM (http://www.ikvm.net/) does.


Could mono become a hybrid CIL/java platform?


This can be obtained easily with IKVM.


Do you plan to implement a Javascript compiler?


Yes. The beginnings of the JScript compiler can be found on SVN. Cesar coordinates this effort.


Can Mono or .NET share system classes (loaded from mscore.dll and other libs) or will it behave like Sun's Java VM?


What you can do with mono is to load different applications in their own application domain: this is a feature of the CLR that allows sandboxing applications inside a single process space. This is usualy exploited to compartmentalize different parts of the same app, but it can also be effectively used to reduce the startup and memory overhead. Using different appdomains the runtime representation of types and methods is shared across applications.


Extending Mono


Would you allow other classes other than those in the specification?


Yes. The Microsoft class collection is very big, but it is by no means complete.
For more information on extending Mono, see our
ideas page.


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).


Is there any way I can develop the class libraries using Linux yet?


Yes. Mono has been self hosting since March 2002.


Is there any way I can install a known working copy of mono in /usr, and an experimental copy somewhere else, and have both copies use their own libraries?


Yes. Just use two installation prefixes.


Portability


Will Mono only work on Linux?




Currently, we are doing our work on Linux-based systems and Windows. We do not expect many Linux-isms in the code, so it should be easy to port Mono to other UNIX variants.


What about Mono on non Linux-based systems?


Our main intention at Novell is to be able to develop GNOME applications with Mono, but if you are interested in providing a port of the Winforms classes to other platforms (frame buffer or MacOS X for example), we would gladly integrate them, as long they are under an open source license.

ion:</b> What operating systems/CPUs do you support

Mono currently runs on Linux, Windows, Solaris, FreeBSD, HP-UX and MacOS X.
The Just-In-Time engine (JIT) is available on x86 and PowerPC, Sparc and S390 processors and can generate code and optimizations tailored for a particular CPU.
Interpreters exist for the Itanium, HP-PA, StrongARM CPUs.


Does Mono run on Windows?


Yes. You can get pre-compiled binaries from http://www.mono-project.com/downloads/index.html


Does Mono run on Linux?


Yes. You can get pre-compiled binaries from http://www.mono-project.com/downloads/index.html


Will I require Cygwin to run mono?


No. Cygwin is only required to build Mono.


Will Mono depend on GNOME?


It will depend only if you are using a particular assembly (for example, for doing Gtk# based GUI applications). If you are just interested in Mono for implementing a 'Hello World Enterprise P2P Web Service', you will not need any GNOME components.


Do you plan to port Rhino to C#?


.
Eto Demerzal has started a Rhino port to C#.


Has anyone succeeded in building a Mac version of the C# environment. If so can you explain how?


Yes, Mono works on Linux/PPC and MacOS X (10.2 and 10.3)


Reusing Existing Code


What projects will you reuse or build upon?




We want to get Mono in the hands of programmers soon. We are interested in reusing existing open source software.


Will I be able to use Microsoft SQL Server 2000 or will I need to switch to a specific Open Source Database. Will I need to recode?


There is no need to rewrite your code as long as you keep using Microsoft SQL Server. If you want to use an open source database, you might need to make changes to your code.


What do I need to watch out for when programming in VB.NET so that I'm sure to be able to run those apps on Linux?




Not making any P/Invoke or DLL calls should and not using anything in the Microsoft namespaces should suffice. Also do not use any Methods/Classes marked as "This type/method supports the .NET Framework infrastructure and is not intended to be used directly from your code." even if you know what these classes/methods do.


Will built-in reporting be supported for crystal reports?


Crystal Reports are proprietary. Someone may try to emulate the behavior, but no-one has yet volunteered.


What about writing to the registry? As I understand it, Linux does not have a counterpart to the registry. Should I avoid relying on that feature?




Try to avoid it. Although there would be a emulation for registry in Mono too. GNOME does have a registry like mechanism for configuration. But Even if gnome has a configuration system similar to the registry, the keys will not be equal, so you will probably end up having to do some runtime detection, and depending on this load an assembly that has your platform-specific hacks.


System.Data.SqlClient with FreeTDS, will you port parts of these to C# and use them?


This has been done. System.Data.SqlClient is a fully managed provider for Microsoft SQL Server 7, 2000, and 2005 databases written in 100% C#. It used FreeTDS and jTDS as resources.


Mono and GCC


Are you working on a GCC front-end to C#?


We are not working on a GCC front-end for C#.


What about making a front-end to GCC that takes CIL images and generates native code?




There is no active work on this area, but Mono already provides pre-compilation services (Ahead-of-Time compilation).


Will you support C/C++ on the Mono VM?


There are no current plans to do this, but a few research efforts in this direction. The concept would be similar to using Managed C++ from Microsoft's implimentation. The issue is that Microsoft's Managed C++ doesn't not compile down fully managed code and so the runtime wouldn't be able to handle the native code for different platforms to easily.


I have a C++ library that I would like to call from Mono, what can I do?


There are a few possible approaches:


  • Use a code generator such as SWIG that parses the C++ code and generates C wrapper functions and C# code which DllImports the C wrappers.

Pro: This permits use of C++ code from C#
Con: Not terribly elegant; Extra layer of C code may impact performance.


  • There was work on a WHIRL-to-IL compiler, which would compile C (and probably C++) into CIL which Mono could execute.

  • Modify GCC's to produce CIL.

  • Use GIMPLE in gcc 4.0

What is the WHIRL-to-IL tion for using C++ with Mono?




WHIRL is the name for the intermediate reprsentation produced by SGI's Open64 compiler.
The Open64 compiler is a modified version of GCC that generates a new intermediate language instead of RTL. This could be the foundation to generate CIL code, and to implement the upcoming Managed extensions to C++ from ECMA.
Open64 (and other derivative forks of GCC) split the gcc front-ends from the backends by using the WHIRL intermediate representation. Kris has begun the implementation of a translator from WHIRL to CIL. So it will be possible to use the GCC compilers to target the CIL.


What about Managed C++?




Once a full translator for WHIRL exists, we are interested in looking at expanding the GCC frontends to include extensions for Managed C++.


Mono and the Basic Language


Does Mono implement the Basic language?


An implementation of the VB.NET language is in progress right now, to find out more about the current state of the compiler see the page on Basic.


What about VB6


Mono does not have current plans to implement VB6 at this point.

The major value of VB6 is reportedly its deep integration with COM-based controls which would not be available on Unix, and it seems to be generally accepted that the major value of VB6 is the availability of third party controls.

An effort to implement a full stack would probably require a COM-stack to be implemented and a way of running existing controls. A task that is outside the scope of Mono.


What about VBScript and VBA?


Those languages are simpler to implement due to the restricted dependency on external COM objects, but there are no plans at this point to implement them by the Mono team.


Performance


How fast will Mono be?


We can not predict the future, but a conservative estimate is that it would be at least 'as fast as other JIT engines'.
Mono's JIT engine has been recently re-architected, and it provides many new features, and layers suitable for optimization. It is relatively easy to add new optimizations to Mono.
The CIL has some advantages over the Java byte code: The existance of structs in addition to classes helps a lot the performance and minimizes the memory footprint of applications.
Generics in the CLI world are first-class citizens, they are not just a strong-typing addition to the language. The generic specifications are embedded into the instruction stream, the JIT uses this information to JIT a unique instances of a method that is optimized for the type arguments.

The CIL is really an intermediate representation and there are a number of restrictions on how you can emit CIL code that simplify creating better JIT engines.
For example, on the CIL, the stack is not really an abstraction available for the code generator to use at will. Rather, it is a way of creating a postfix representation of the parsed tree. At any given call point or return point, the contents of the stack are expected to contain the same object types independently of how the instruction was reached.


Mono and Portable.NET


What are the differences between Mono and Portable.NET?


Most of Mono is being written using C#, with only a few parts written in C (The JIT engine, the runtime, the interfaces to the garbage collection system).

It is easier to describe what is unique about Mono:


  • An advanced native-code compilation engine: Both just-in-time compilation (JIT) and pre-compilation of CIL bytecodes into native code are supported.

  • A foundation for code optimization: The new code generator in Mono builds on the experience of our first JIT engine, and enables us to implement various advanced compiler optimization tricks. With an SSA-framework, plenty of new optimizations are possible.

The current list of optimizations are: Peephole postpass, Branch optimizations, Inline method calls, Constant folding, Constant propagation, Copy propagation, Dead code elimination, Linear scan global reg allocation, Conditional moves, Emit per-domain code, Instruction scheduling, Intrinsic method implementations, Tail recursion and tail calls, Loop related optimizations, Fast x86 FP compares, Leaf procedures optimizations


  • A self-hosting C# compiler written in C#, which is clean, easy to maintain.

  • A multi-platform runtime engine: both a JIT engine and an interpreter exist. The JIT engine runs currently on x86, PowerPC, S390 and Sparc systems, while the interpreter works on x86, SPARC, StrongARM, s390 and PowerPC systems.

The JIT engine is being ported to amd64 systems at this time.


  • The JIT engine is written using a portable instruction selector which not only generates good code but is also the foundation to re-target the JIT engine to other systems.

  • Full support for remoting in the runtime.

  • The C# compiler, the JIT engine and the class libraries are mature enough that the whole system has been self-hosting since April 2002. This means that we develop Mono completely with itself at this point.

By forcing ourselves to use our own code to develop our tools, we bug fix problems rapidly, and the system is overall more robust and tested than if we did not.


  • Our class libraries are licensed under the terms of the MIT X11 license which is a very liberal license as opposed to the GNU GPL with exceptions, this means that Mono can be used in places where the GPL with exceptions is not permissible.

  • Mono has a complete Web Services stack: we implement ASP.NET web servers and web clients as well as implementing the Remoting-based SOAP infrastructure.

  • Remoting implementation: Mono has a complete remoting infrastructure that is used in our own codebase to provide added functionality and performance to our ASP.NET engine and more.

  • Mono has a complete C# 1.0 implementation and has been stress tested a lot more than Portable.NET's compiler.

  • Mono's C# compiler flags more errors and warnings on invalid C# code.

  • Mono's C# compiler is a CLS consumer and producer, which means that it will enforce during development the CLS rules.

  • Mono's C# compiler has strong error handling and has closer adherence to the specification with support for definite assignment (required to generate verifiable IL code).

  • Mono's C# compiler is written in C# which is easier for new developers to come in and improve, fix and tune. The Mono C# compiler in C# is faster than their C-based compiler.

  • Preview of C# 2.0: a work in progress for a 2.0 implementation of our compiler is available (iterators, generics and anonymous methods are available in our "preview" compiler).

  • Mono has a complete Reflection and Reflection.Emit: these are important for advanced applications, compilers and dynamic code generation (Applications like IKVM and IronPython depend on this feature for example).

  • Mono has a complete managed XML stack: XML, XPath, XML Serializer, XML Schema handling are fully functional, feature complete and tuned for performance. In addition to the Microsoft API, mono ships with the Mono.Xml.Ext library that contains an XQuery/XPath2 implementations.

  • Mono has a complete cryptography stack: we implement the 1.0 and 1.1 APIs as well as using our fully managed stack to implement the SSL/TLS transports.


  • Mono includes LDAP support.

  • Mono has a larger community of active developers. Full time developer from companies (Novell and Mainsoft) as well as volunteers from the community.

In general, Mono is more mature and complete since it has been used to develop itself, which is a big motivator for stability and correctness, while Portable.NET remains pretty much an untested platform.