What's the point of Mono on Windows
WindowsMonoWindows Problem Overview
This may be a dumb question...but I was just looking into the Mono project and they have a section about installing Mono on Windows. But, since Windows obviously already has the .NET runtime can anyone tell me what exactly is the point of having Mono for Windows? Does it help with cross platform development or something?
Windows Solutions
Solution 1 - Windows
There are a couple of features Mono has that .NET doesn't.
Mono is highly modular. You can break it apart in tiny little pieces and only deploy exactly those parts that you need. Don't want System.Xml? Fine, it's gone.
Mono is embeddable. You can host it inside your C/C++ application, to allow users to script it from a safe managed sandboxed environment. The most famous example of this is mod_mono, which hosts Mono inside the Apache webserver, and is how ASP.NET is implemented in Mono, for example. This feature goes great together with the modularization mentioned above.
This has already been mentioned: static linking. Also goes great together with modularization.
Compiler as a Service is another one. Anders Hejlsberg has been talking about it for a long time, and maybe, just maybe it is going to be ready for C# 5.0. Well, Mono already has it, and actually had it for years.
Miguel de Icaza, Mono's Lead Developer also has an initiative that he calls "Embrace and Extend.NET", which extends the CLI in ways not (currently) possible with other CLI implementations (including .NET). So far, Embrace and Extend.NET has three features.
Mono.Simd, which gives safe and controlled access to the SIMD instructions of the underlying CPU (e.g. SSE on Intel or AltiVec on PowerPC). Used for Games and Graphics.
64 Bit array indices, which are allowed by the ECMA specification, but Mono is the only VM that actually provides them. Used in supercomputing.
And most recently, continuations. This is actually the first time that Mono strays outside the realm of the specification: long array indices are perfectly valid as per the spec, and Mono.Simd also works on every CLI compliant implementation (albeit very S-L-O-W), but Mono.Tasklet needs special support from the VM that is not part of either CLI or .NET. This is used for game logic and e.g. in Second Life.
Solution 2 - Windows
Because Mono Doesn't implement .Net 100% the same as the MS .Net Framework, it's good that you can test out on Mono without having to run on Linux. Also Mono has bindings to make forms with GTK which MS doesn't support.
Solution 3 - Windows
Mono does some things the .Net doesn't.
For example, mono supports static linking so you can build, compile, and distribute your app without requiring a separate run-time installer. If you built an app to rely on mono to be cross-platform, there are some differences from .Net and so sticking with mono on Windows is a greater guarantee of compatibility.
.Net does some things that mono doesn't.
There are a few places in the BCL that are not yet ported for mono, such as WPF and Winforms, among others.
If you want an app that will also work on mac/linux you probably want to develop for mono first, even if you're doing the most of the work on windows.
Note: all of this pre-dates .Net Core/Standard.
Solution 4 - Windows
From Mono's technical FAQ:
> Why support Windows, when you can run the real thing? > > There are various reasons: > > > 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. > > It assists us since we can isolate problems in Mono by > partitioning the problem (is it a > runtime issue, or an OS issue?). > > 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. > > Mono does not heavily modify the windows registry, update system DLLs, > install DLLs to the Windows/System32 > path. > > It helps Windows-based developers to test their code under > Mono before they deploy into Linux. > > Mono and applications that embed Mono can be deployed without an > installer (you can "xcopy" deploy your > application and the required Mono > files without installing the .NET > runtime).
Solution 5 - Windows
If you want to develop a cross-platform application in C#, then using Microsoft's implementation is not the smartest thing, as there is no fully compatible alternative for other platforms.
So using Mono on Windows to develop applications ensures that you'll have little trouble porting it to other OS (provided you avoid other pits such as P/Invoke).
Solution 6 - Windows
Some people have used it because they are not allowed to install the .Net framework on their Windows PC's, due to the amount of registry and system files mucking it does. (In tightly controlled environments.)
Mono, on the other hand, is self contained in Program Files, and only writes a registry key with a path it in (which isn't necessary to run).
I think this is kinda silly, but it is something that multiple users have told us.
Solution 7 - Windows
It is mostly there as an aid to developing Mono apps for the Mono specific libraries. Also for helping to advance the cause, so that developers can work in their natural environment when developing for Mono.
Solution 8 - Windows
While not of widespread interest, there are a few cases where mono has improvements over the standard Microsoft runtime. Migel gave a talk on some of these at PDC this year:
See these posts:
Solution 9 - Windows
also even if you have program dynamically linked with Mono, you can have that compiled .exe and Mono runtime on pendrive and goto another computer with no .NET/Mono installed, and run that program on the new PC without any runtime installation. ie, It leads to portable apps (particularly useful as portable usb pen drive apps) This is not possible with .NET. You have to have .NET runtime installed in a particular installer way,ie, runtime containing folder copy and paste not possible.
Solution 10 - Windows
I think the main reason they did this is so they can run .NET applications on Mono and .NET side-by-side to compare them. Also, there are a few applications that depend on Mono libraries.
Solution 11 - Windows
To add to numerous reasons mentioned in other answers, Mono for Windows may be required to be installed on Wine to allow running .Net applications inside Wine.