Which Linux Distribution Is Best for Developing a Mono Application in a Virtual Machine

Which Linux distribution is best for developing a Mono application in a virtual machine?

Mono is primarily written on and tested on openSUSE. The packages we release are for openSUSE. In fact, we release a VMWare Image of openSUSE with the new version of Mono all set up and ready to go:

http://www.go-mono.com/mono-downloads/download.html

Having said that, we have a great community of people who work to ensure Mono runs well and is packaged on all the major distributions, such as Fedora and Ubuntu.

Which Linux distro is best for running in a virtual machine, for programming research?

I installed ubuntu 8.10 in a virtual machine on my Vista 64-bit laptop. I attempted the install with Virtual PC, VM Ware and Virtual Box from SUN. Virtual Box was the only vm software that I was successful with from the start. In the setup you choose that you are installing linux as your guest OS and everything works without spending your evening sifting through blogs trying to get install to work.

Is .NET/Mono or Java the better choice for cross-platform development?

Well....Java is actually more portable. Mono isn't implemented everywhere, and it lags behind the Microsoft implementation significantly. The Java SDK seems to stay in better sync across platforms (and it works on more platforms).

I'd also say Java has more tool availability across all those platforms, although there are plenty of tools available for .NET on Windows platforms.

Update for 2014

I still hold this opinion in 2014. However, I'll qualify this by saying I'm just now starting to pay some attention to Mono after a long while of not really caring, so there may be improvements in the Mono runtime (or ecosystem) that I haven't been made aware of. AFAIK, there is still no support for WPF, WCF, WF, of WIF. Mono can run on iOS, but to my knowledge, the Java runtime still runs on far more platforms than Mono. Also, Mono is starting to see some much improved tooling (Xamarin), and Microsoft seems to have a much more cross-platform kind of attitude and willingness to work with partners to make them complimentary, rather than competitive (for example, Mono will be a pretty important part of the upcoming OWIN/Helios ASP.NET landscape). I suspect that in the coming years the differences in portability will lessen rapidly, especially after .NET being open-sourced.

Update for 2018

My view on this is starting to go the other way. I think .NET, broadly, particularly with .NET Core, has started to achieve "portability parity" with Java. There are efforts underway to bring WPF to .NET Core for some platforms, and .NET Core itself runs on a great many platforms now. Mono (owned by Xamarin, which is now owned by Microsoft) is a more mature and polished product than ever, and writing applications that work on multiple platforms is no longer the domain of deep gnosis of .NET hackery, but is a relatively straightforward endeavor. There are, of course, libraries and services and applications that are Windows-only or can only target specific platforms - but the same can be said of Java (broadly).

If I were in the OP's shoes at this point, I can think of no reason inherent in the languages or tech stacks themselves that would prevent me from choosing .NET for any application going forward from this point.

Is program written in MONO as efficient as the program on .net framework

Software you write will generally run on Mono with similar performance (it does implement a VM and JIT compiler just like .NET does), if you only use components that are also implemented in Mono, and therein lies the problem:

Mono does not implement WPF!

Generally you will see, that Mono lacks support for a lot of the new any fancy Microsoft APIs like WPF, WCF and EntityFramework. Additionally, if you only want to develop for Windows, the .NET Framework is the way to go, it is a lot more polished and specifically designed for Windows. If you are a C#/VB developer who desperately wants to develop for Mac OS or Linux, it is worth taking a look at Mono - otherwise you can safely ignore it.

Mono API Compatibility

Mono on VS2010?

You can develop in Linux using MonoDevelop.

You can also develop on Windows using Visual Studio 2010 Express Edition, and target the Microsoft .NET Framework. You can then run your assemblies through the Mono Migration Analyzer (MoMA) to make sure they'll run successfully on Linux/Mono. Since Mono uses the same standard IL as the Microsoft framework, the application will run unchanged on Linux, provided you stick to supported portions of the framework.

How does Mono work

This is an old question (with an already selected answer) but I do not believe the question has really been answered well.

First, a little background...

How does .NET work?

A traditional Windows .EXE file is a binary file that represents a series of machine language instructions that your computer understands and that makes calls into the Win32 API which are parts of Windows that deliver services that applications can take advantage of. The machine language used is very specific to your kind of computer and the Win32 calls make the executable very dependent on Windows. A .NET executable is not like that.

It is important to realize that a .NET executable (.EXE file) is not actually a native Windows application. Windows itself does not understand how to run the code in a .NET executable. Your computer does not understand it either.

Much like Java, a .NET application is made up of instructions in a language called CIL (Common Intermediate Language) that you can think of as the machine language for an idealized computer that does not really exist. In .NET, the software implementation of this idealized machine is called the Common Language Runtime (CLR). The equivalent in the Java world is called the Java Virtual Machine (JVM). In Java, the equivalent to CIL is called Java bytecode. CIL is sometimes called MSIL (Microsoft Intermediate Language).

CIL is designed to run on the CLR (an idealized machine) but is otherwise platform independent, which means that the CIL does not care what kind of computer you have or what operating system you are running.

Just as you need a native version of the Java JVM on each platform on which you want to run Java, you need a native version of the CLR to run .NET CIL executables. The CLR is a native Windows application just like the traditional Win32 EXE files described above. The CLR itself is specific to the Windows implementation and computer architecture on which it was designed to run.

It does not matter what .NET language you start with (C#, VisualBasic, F#, IronPython, IronRuby, Boo, etc.), they all get compiled down to CIL bytecode. You can easily "disassemble" a CIL program into a form of object-oriented assembly language that is easily readable by humans. You can write a program in CIL directly yourself but few people do.

On Windows, the CLR compiles this CIL code Just-in-Time (JIT) right when you run the executable--just before the code is actually run. This means that the CIL bytecode is converted (compiled) to actual machine code that runs natively on your computer. This part of the CLR is called the JIT compiler or often just the JIT.

To date, Microsoft has released four versions of the CLR: 1.0, 1.1, 2.0, and 4.0. You need to have the right version of the CLR installed on your machine if you want to run .NET executables targeting that runtime. The CLR 2.0 supports .NET 2.0, 3.0, and 3.5 applications. For other versions of .NET, the .NET version maps cleanly to the CLR version.

In addition to the JIT/CLR, .NET provides a host of libraries (assemblies) that make up the rest of the .NET framework and that provide a host of capabilities and services that .NET applications can call upon. The great majority of these assemblies are pure CIL code which runs on the CLR. On Windows, a some make calls into the Win32 API as well. When you install .NET, you are installing the CLR, the class libraries (framework), and a bunch of development tools. Each version of the CLR generally requires a complete set of these "framework" assemblies. Some versions of .NET (eg. 3.0 and 3.5) added additional framework assemblies without updating the CLR or the existing assemblies associated with that CLR.

The Portable Executable (PE) file format that a Windows .EXE file is delivered in contains a header that describes the executable and identifies the file as a .NET file or a native Win32 file. When Windows tries to run a .NET file, it sees this header and automatically invokes the CLR on your behalf. This is why .NET EXE files appear to run natively on Windows.

Ok, so how does Mono work?

Mono implements the CLR on Linux, Mac, and other platforms. The Mono runtime (the CLR) is a native application written mostly in the C language and compiled down to machine language code for the computer system on which is designed to run. Like on Windows, the Mono runtime is specific to the Operating System and kind of machine you are using.

Just like on Windows, the Mono runtime (the CLR) compiles the CIL bytecode in your .NET executable Just-in-time to native code that your computer can understand and execute. In this way, a .NET file is just as "native" to Linux as it is to Windows.

To port Mono to a new architecture you need to port the JIT/CLR. This is just like porting any native application to a new platform.

How well .NET code runs on Linux or Mac is really just a question of how well the CLR is implemented on these systems. In theory, the Mono CLR could execute .NET code on these systems much better than the MS version of .NET does on Windows. In practice, the MS implementation is generally superior (though not in all cases).

In addition to the CLR, Mono provides most of the rest of the libraries (assemblies) that make up the .NET framework. Just as with the Microsoft version of .NET (in fact more so) the Mono assemblies are provided as CIL bytecode. This makes it possible to take a *.dll or *.exe file from Mono and run it unmodified on Windows, Mac, or Linux as CIL is the "native" language of the CLR implementations on these systems.

Just like on Windows, Mono supports multiple versions of the CLR and the associated assemblies:

Very early versions of Mono (before 1.2?) only supported CLR 1.0 or 1.1.
Mono did not support big chunks of the 2.0 framework until it's own 2.0 version.

Mono versions up to version 2.4 supported both CLR 1.1 and CLR 2.0 applications.

Starting with Mono 2.6, CLR 4.0 was added but CLR 2.0 was still the default.

Starting with Mono 2.8 the CLR 4.0 became the default and the CLR 1.1 is no longer supported.

Mono 2.10 continues to use the CLR 4.0 as default and also to support the CLR 2.0.

Just like the real .NET (but in far fewer cases) there are some Mono assemblies that call into native libraries. In order to make the System.Drawing assembly work on Mono, the Mono team wrote a Linux program to simulate the GDI+ portion of the Win32 API on Linux. This library is called 'libgdiplus'. If you compile Mono from source, you will notice that you need to build this 'libgdiplus' file before you can build 'mono'. You do not need 'libgdiplus' on Windows because the GDI+ portion of the Win32 API is already part of Windows. A full port of Mono to new platforms requires this 'libgdiplus' library to be ported as well.

In areas where the design of the .NET library is overly influenced by the design of Windows, and a poor fit for systems like Mac or Linux, the Mono team has written extensions to the .NET framework. The Mono extensions are also just CIL bytecode and generally work just fine on .NET.

Unlike on Windows, Linux generally does not detect .NET executables and launch the CLR by default. The user must usually run the CLR directly by typing 'mono appname.exe' or something similar. Here 'mono' is the application that implements the CLR and 'appname.exe' is the EXE file that contains the .NET code to be executed.

To make things easier for users, Mono applications are often wrapped in a shell script that launches the CLR. This hides the fact that the CLR is being used just as in Windows. It is also possible to tell Linux to launch the CLR when a file using the PE file format is encountered. This is usually not done as the PE file format is also used for native Win32 Windows executables which of course the CLR (Mono) does not support.

There is no technical reason why a PE launcher could not be used by Linux which then launches either a system that understands native Windows code (like Wine) or the CLR (Mono) as appropriate. This has simply not been done to my knowledge.

Back and forth

Any .NET code that sticks to "fully managed" code, which means it does not call into non-.NET code, should work fine on Mono on all platforms. I routinely use compiled .NET assemblies from Windows (for which I do not have the code) on Linux and Mac.

I can also take any code that I compile on Mono and run that on .NET on Windows. I can provide a client some code I compiled with Mono and not worry if he is on 32-bit or 64-bit Windows for example. The client does need to have the right version of .NET (the right CLR) installed fo course. CLR 2.0 has been around for a very long time and you can bet almost all Windows users have it installed. The Mono compilers and other code are also just CIL executables and so they run fine on Windows if you like.

Mono compatibility is good enough that large chunks of actual Microsoft code, like ASP.NET MVC, can be taken (where legal to do so) from the actual MS version of .NET and run on Mac or Linux. In general, the Mono team has done a great job of implementing both the CLR and the rest of the framework (class libraries/assemblies).

ASP.NET

On Windows, the Internet Information Server (IIS) knows how to call into the CLR to execute .NET as part of a web application. On Linux/Mac there is an Apache module (mod_mono) that provides similar capabilities to the Apache webserver. This application is written in C and must also be ported to new architectures.

Porting Mono

This discussion has identified parts of Mono that are built as "native" executables and must exist on a system on which you want to run .NET applications.

• The CLR (including JIT compiler) - generally known as Mono
• libgdiplus (for systems which do not natively support the GDI+ API [only Windows does])
• mod_mono (to allow Apache to invoke the CLR for .NET web applications)

These three components, with the addition of the class libraries, provide a .NET environment that looks "native" to the .NET executable files you need to run.

That is how Mono works.

How a Windows Developer can most easily get his software to work well under Wine

Download VMWare and an Ubuntu virtual machine (Ubuntu is a popular Linux distribution) from the VMWare site. This will provide you with a working Linux O/S inside your Windows environment without needing to install Linux manually.

You can then use the instructions here to install Wine, that Wiki page also provides you with some instructions on how to use it.

If you follow what Adam Rosenfield suggested and just try running your application in Wine unmodified, you will be able to determine quickly whether there are problems. My guess would be that there are some, otherwise your users would not have contacted you about it :)

There are many ways for getting help with debugging applications in Wine, consult the website for options and pick a few ways that suit you. As always, it's best not to rely on a single channel for communication.

Also, if you are more comfortable with developing in Windows, the approach of using a virtual machine will allow you to compile your code as usual in Windows and copy the binary into the virtual machine for testing (Ubuntu supports browsing/mounting Windows shares).

---

Related Topics