Hubbry Logo
Mono (software)Mono (software)Main
Open search
Mono (software)
Community hub
Mono (software)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Mono (software)
Mono (software)
Mono (software)
View on Wikipedia
from Wikipedia
Mono
Original authorXimian
DeveloperWineHQ
Initial releaseJune 30, 2004; 21 years ago (2004-06-30)
Stable release
6.12.0.206 / February 13, 2024; 23 months ago (2024-02-13)[1]
Repository
Written inC, C#, XML
Operating systemWindows, macOS, Linux, IBM AIX, IBM i[2]
PlatformIA-32, x64, IA-64, ARM, MIPS, RISC-V, PowerPC, SPARC, S390
TypeSoftware framework
LicenseMIT License[3]
Websitewww.mono-project.com

Mono is a free and open-source software framework that aims to run software made for the .NET Framework on Linux and other OSes. Originally by Ximian which was acquired by Novell, it was later developed by Xamarin which was acquired by Microsoft.[4] In August 2024, Microsoft transferred ownership of Mono to WineHQ.[5]

History

[edit]
Mono booth at OSCON 2009 in San Jose, California

When Microsoft first announced their .NET Framework in June 2000 it was described as "a new platform based on Internet standards",[6] and in December of that year the underlying Common Language Infrastructure was published as an open standard, "ECMA-335",[7] opening up the potential for independent implementations.[8] Miguel de Icaza of Ximian believed that .NET had the potential to increase programmer productivity and began investigating whether a Linux version was feasible.[9] Recognizing that their small team could not expect to build and support a full product, they launched the Mono open-source project, on July 19, 2001, at the O'Reilly conference.

After three years of development, Mono 1.0 was released on June 30, 2004.[10] Mono evolved from its initial focus of a developer platform for Linux desktop applications to supporting a wide range of architectures and operating systems - including embedded systems.[11]

Novell acquired Ximian in 2003. After Novell was acquired by Attachmate in April 2011, Attachmate announced hundreds of layoffs for the Novell workforce,[12] putting in question the future of Mono.[13][14]

On May 16, 2011, Miguel de Icaza announced in his blog that Mono would continue to be supported by Xamarin, a company he founded after being laid off from Novell. The original Mono team had also moved to the new company. Xamarin planned to keep working on Mono and had planned to rewrite the proprietary .NET stacks for iOS and Android from scratch, because Novell still owned MonoTouch and Mono for Android at the time.[15] After this announcement, the future of the project was questioned, MonoTouch and Mono for Android being in direct competition with the existing commercial offerings now owned by Attachmate, and considering that the Xamarin team would have difficulties proving that they did not use technologies they formerly developed when they were employed by Novell for the same work.[16] However, in July 2011, Novell, now a subsidiary of Attachmate, and Xamarin, announced that it granted a perpetual license to Xamarin for Mono, MonoTouch and Mono for Android, which officially took stewardship of the project.[17][18]

On February 24, 2016, Microsoft announced it had signed a definitive agreement to acquire Xamarin.[19]

On August 27, 2024, Microsoft transferred ownership of Mono to WineHQ, the developer team of Wine, a Windows compatibility layer.[5]

Current status and roadmap

[edit]

Mono's current version is 6.12.0 (as of June 2024). This version provides the core API of the .NET Framework and support for Visual Basic.NET and C# 7.0. LINQ to Objects, XML, and SQL are part of the distribution. Windows Forms 2.0 is also supported, but not actively developed, and as such its support on Mono is incomplete.[20] Version 4.0 was the first version that incorporates Microsoft original source code that was released by Microsoft as part of the .NET Core project.

As of January 14, 2021, Mono has full support for all the features in .NET 4.7 except Windows Presentation Foundation (WPF) (which the Mono team do not plan to support due to the amount of work it would need)[20] and Windows Workflow Foundation (WF), and with only limited support for Windows Communication Foundation (WCF) and the ASP.NET async stack. However, System.Web and WCF are candidates for 'almost immediate' porting from the .NET reference source back to Mono.[21] Some missing parts of the .NET Framework are under development in an experimental Mono subproject called Olive.[22]

The Mono project has also created a Visual Basic .NET compiler and a runtime designed for running VB.NET applications. It is currently being developed by Rolf Bjarne Kvinge.

Moonlight

[edit]
Main article: Moonlight (runtime)

An open-source implementation of Microsoft Silverlight, called Moonlight, has been included since Mono 1.9.[23] Moonlight 1.0, which supports the Silverlight 1.0 APIs, was released January 20, 2009. Moonlight 2.0 supports Silverlight 2.0 and some features of Silverlight 3.0.[24] A preview release of Moonlight 3.0 was announced in February 2010 and contains updates to Silverlight 3 support.[25]

The Moonlight project was abandoned on May 29, 2012.[26] According to Miguel, two factors sealed the fate of the project: Microsoft added "artificial restrictions" that "made it useless for desktop programming", and the technology had not gained enough traction on the Web. In addition, Silverlight itself was deprecated by Microsoft by 2012.

Mono components

[edit]

Mono consists of three groups of components:

  1. Core components
  2. Mono/Linux/GNOME development stack
  3. Microsoft compatibility stack

The core components include the C# compiler, the virtual machine for the Common Language Infrastructure and the core class libraries. These components are based on the Ecma-334 and Ecma-335 standards,[27] allowing Mono to provide a standards compliant, free and open-source CLI virtual machine. Microsoft issued a statement that covers both standards under their Community Promise license.[28]

The Mono/Linux/GNOME development stack provide tools for application development while using the existing GNOME and free and open-source libraries. These include: Gtk# for graphical user interface (GUI) development, Mozilla libraries for working with the Gecko rendering engine, Unix integration libraries (Mono.Posix), database connectivity libraries, a security stack, and the XML schema language RelaxNG. Gtk# allows Mono applications to integrate into the Gnome desktop as native applications. The database libraries provide connectivity to the object-relational database db4o, Firebird, Microsoft SQL Server (MSSQL), MySQL, Open Database Connectivity (ODBC), Oracle, PostgreSQL, SQLite, and many others. The Mono project tracks developing database components at its website.[29]

The Microsoft compatibility stack provides a pathway for porting Windows .NET applications to Linux. This group of components include ADO.NET, ASP.NET, and Windows Forms (and libgdiplus), among others. As these components are not covered by Ecma standards, some of them remain subject to patent fears and concerns.

Framework architecture

[edit]

The major components of Mono include:

Code Execution Engine

[edit]

The Mono runtime contains a code execution engine that translates ECMA CIL byte codes into native code and supports a number of processors: ARM, MIPS (in 32-bit mode only), SPARC, PowerPC, z/Architecture, IA-32, x86-64 and IA-64 for 64-bit modes.

The code generator is exposed in three modes:

  • Just-in-time (JIT) compilation: The runtime will turn ECMA CIL byte codes into native code as the code runs.
  • Ahead-of-Time (AOT) compilation: this code turns the ECMA CIL byte codes (typically found on a .exe or .dll file) and generates native code stored in an operating system, architecture and CPU specific file (for a foo.exe file, it would produce foo.exe.so on Linux). This mode of operation compiles most of the code that is typically done at runtime. There are some exceptions like trampolines and other administrative code that still require the JIT to function, so AOT images are not fully standalone.
  • Full Static Compilation: this mode is only supported on a handful of platforms and takes the Ahead-of-Time compilation process one step further and generates all the trampolines, wrappers and proxies that are required into a static file that can be statically linked into a program and eliminates the need for a JIT at runtime. This is used on Apple's iOS, Sony's PlayStation 3 and Microsoft's Xbox 360 operating systems.[citation needed]

Starting with Mono 2.6, it is possible to configure Mono to use the LLVM as the code generation engine instead of Mono's own code generation engine. This is useful for high performance computing loads and other situations where the execution performance is more important than the startup performance.

Starting with the Mono 2.7 preview, it is no longer necessary to pick one engine over the other at configuration time. The code generation engine can be selected at startup by using the --llvm or --nollvm command line arguments, and it defaults to the fast-starting Mono code generation engine.

Starting with Mono 5.18, support for LLVM is a default configuration option. Previous versions required a special LLVM fork, but now mono can fall back to its own code generator when it encounters something not handled by LLVM.[30]

Garbage collector

[edit]

As of Mono 2.8, the Mono runtime ships with two garbage collectors: a generational collector and the Boehm–Demers–Weiser Conservative Garbage Collector. The Boehm garbage collector could exhibit memory leaks on certain classes of applications, making it unsuitable for some long-running server applications.[31][32] Mono switched to Simple Generational GC (SGen-GC) as the default collector in version 3.1.1.

The SGen garbage collector has many advantages over a traditional conservative scanner. It uses generational garbage collection where new objects are allocated from a nursery, during the garbage collection cycle, all objects that survived are migrated to an older generation memory pool. The idea is that many objects are transient and can quickly be collected and only a handful of objects are long-term objects that live for the entire life of the application. To improve performance this collector assigns memory pools to each thread to let threads allocate new memory blocks without having to coordinate with other threads. Migration of objects from the nursery to the old generation is done by copying the data from the nursery to the old generation pool and updating any live pointers that point to the data to point to the new location. This can be expensive for large objects, so Mono's SGen uses a separate pool of memory for large objects (Large Object Section) and uses a mark-and-sweep algorithm for those objects.[31]

Class library

[edit]

The class library provides a comprehensive set of facilities for application development. They are primarily written in C#, but due to the Common Language Specification they can be used by any .NET language. The class library is structured into namespaces, and deployed in shared libraries known as assemblies. Speaking of the .NET Framework is primarily referring to this class library.[33]

Namespaces and assemblies

[edit]

Namespaces are a mechanism for logically grouping similar classes into a hierarchical structure. This prevents naming conflicts. The structure is implemented using dot-separated words, where the most common top-level namespace is System, such as System.IO and System.Net. There are other top-level namespaces as well, such as Accessibility and Windows. A user can define a namespace by placing elements inside a namespace block.

Assemblies are the physical packaging of the class libraries. These are .dll files, just like (but not to be confused with) Win32 shared libraries. Examples of assemblies are mscorlib.dll, System.dll, System.Data.dll and Accessibility.dll. Namespaces are often distributed among several assemblies and one assembly can be composed of several files.

Common Language Infrastructure and Common Language Specification

[edit]

The Common Language Infrastructure (CLI) as implemented by the Common Language Runtime (CLR), is implemented by the Mono executable. The runtime compiles and executes .NET applications. The common language infrastructure is defined by the ECMA standard.[27] To run an application, you must invoke the runtime with the relevant parameters.

The Common Language Specification (CLS) is specified in chapter 6 of ECMA-335 and defines the interface to the CLI, such as conventions like the underlying types for Enum. The Mono compiler generates an image that conforms to the CLS. This is the Common Intermediate Language. The Mono runtime takes this image and runs it. The ECMA standard formally defines a library that conforms to the CLS as a framework.

Managed and unmanaged code

[edit]

Within a native .NET/Mono application, all code is managed; that is, it is governed by the CLI's style of memory management and thread safety. Other .NET or Mono applications can use legacy code, which is referred to as unmanaged, by using the System.Runtime.InteropServices libraries to create C# bindings. Many libraries which ship with Mono use this feature of the CLI, such as Gtk#.

Mono-specific innovations

[edit]

Mono has innovated in some areas with new extensions to the core C# and CLI specifications:

  • C# Compiler as a Service (Use the C# compiler as a library).[34]
  • C# Interactive Shell.[35]
  • SIMD support[36] as part of the Mono.SIMD namespace, where method calls to special vector types are directly mapped to the underlying processor CPU SIMD instructions.
  • Full static compilation of .NET code[37] (used on Mono/iPhone, Mono/PS3).
  • Mono coroutines (used to implement micro-threading code and continuations, mostly for game developers).[38]
  • Assembly injection to live processes.[39]
  • Use of LLVM as JIT backend.
  • Cxxi and CppSharp direct interop with C++ code and libraries.

In addition, Mono is available on a variety of operating systems and architectures.[40]

System requirements

[edit]

Windows 7, Windows 8, Windows 8.1, Windows 10, macOS or Linux

[edit]

Several projects extend Mono and allow developers to use it in their development environment. These projects include:

Cross-platform:

  • Banshee Media Player (stalled), a cross-platform music media player built with Mono and Gtk# and also a driver of dozens of C#-based libraries and projects for media handling.
  • Beagle (unmaintained), a search system for Unix systems.
  • Gecko#, bindings for embedding the layout engine used in Mozilla (Gecko).
  • Gtk#, C# wrappers around the underlying GTK and GNOME libraries, written in C and available on Linux, MacOS and Windows.
  • Mono Migration Analyzer (MoMA), a tool which aids Windows .NET developers in finding areas in their code that might not be cross-platform and therefore not work in Mono on Linux and other Unixes. Not upgraded since Mono 2.8 (2013); use Microsoft's .NET Portability Analyzer (dotnet-apiport) instead.
  • MonoCross, a cross-platform model–view–controller (MVC) design pattern where the Model and Controller are shared across platforms and the Views are unique for each platform for an optimized User Interface. The framework requires Xamarin.iOS and Xamarin.Android.
  • MvvmCross, a cross-platform model–view–viewmodel (MVVM) framework utilizing Xamarin.iOS and Xamarin.Android for developing mobile apps.
  • MonoDevelop an open-source and cross-platform integrated development environment that supports building applications for ASP.NET, Gtk#, Meego, MonoTouch and Silverlight/Moonlight.
  • Moonlight (discontinued), an implementation of Silverlight that uses Mono.
  • OpenTK, a managed binding for OpenGL, OpenCL and OpenAL.
  • QtSharp, C# bindings for the Qt framework.
  • Resco MobileBusiness, a cross-platform developer solution for mobile clients.
  • Resco MobileCRM, a cross-platform developer solution for mobile clients synchronized with Microsoft Dynamics CRM.
  • ServiceStack a high-performance open-source .NET REST web services framework that simplifies the development of XML, JSON and SOAP web services.
  • SparkleShare an open-source client software that provides cloud storage and file synchronization services.
  • Tao (superseded by OpenTK), a collection of graphics and gaming bindings (OpenGL, SDL, GLUT, Cg).
  • Xwt, a GUI toolkit that maps API calls to native platform calls of the underlying platform, exposing one unified API across different platforms and making possible for the graphical user interfaces to have native look and feel on different platforms. It enables building GUI-based desktop applications that run on multiple platforms, without having to customizing code for different platforms. Xwt API is mapped to a set of native controls on each supported platform. Features that are not available on specific platforms are emulated by using native widgets, which is referred to as hosting in the Xwt context.[41] Xwt was partially used as GUI toolkit (beside GTK#) in the development of the Xamarin Studio.[42] Supported "backend" engines are: WPF engine and Gtk engine (using Gtk#) on Windows, Cocoa engine (using MonoMac) and Gtk engine (using Gtk#) on Mac OS X, and Gtk engine (using Gtk#) on Linux.[43]

macOS:

  • Cocoa# – wrappers around the native macOS toolkit (Cocoa) (deprecated).
  • Monobjc – a set of bindings for macOS programming.
  • MonoMac – newer bindings for macOS programming, based on the MonoTouch API design.

Mobile platforms:

  • MonoDroid. Mono for the Android operating system. With bindings for the Android APIs.
  • MonoTouch. Mono for the iPhone, iPad and iPod Touches. With bindings to the iOS APIs.

Windows:

Other implementations

[edit]

Microsoft has a version of .NET 2.0 now available only for Windows XP, called the Shared Source CLI (Rotor). Microsoft's shared source license may be insufficient for the needs of the community (it explicitly forbids commercial use).

Free Software Foundation's decommissioned Portable.NET project.[44]

MonoDevelop

[edit]
Main article: MonoDevelop

MonoDevelop is a free integrated development environment primarily designed for C# and other .NET languages such as Nemerle, Boo, and Java (via IKVM), although it also supports languages such as C, C++, Python, and Vala. MonoDevelop was originally a port of SharpDevelop to Gtk#, but it has since evolved to meet the needs of Mono developers. The IDE includes class management, built-in help, code completion, Stetic (a GUI designer), project support, and an integrated debugger.

The MonoDoc browser provides access to API documentation and code samples. The documentation browser uses wiki-style content management, allowing developers to edit and improve the documentation.

Xamarin.iOS and Xamarin.Android

[edit]

Xamarin.iOS and Xamarin.Android, both developed by Xamarin, were implementations of Mono for iPhone and Android-based smartphones. Previously available only for commercial licensing,[45] after Microsoft's acquisition of Xamarin in 2016, the Mono runtime itself was relicensed under MIT license[46] and both Xamarin.iOS and Xamarin.Android are being made free and open-source.[47]

Xamarin.iOS and Xamarin.Android reached end-of-life on May 1, 2024, being integrated directly into .NET.[48][49] Microsoft recommends migration to .NET MAUI.[49]

Xamarin.iOS

[edit]

Xamarin.iOS (previously named MonoTouch) was a library that allows developers to create C# and .NET based applications that run on the iPhone, iPod and iPad devices. It was based on the Mono framework and developed in conjunction with Novell. Unlike Mono applications, Xamarin.iOS "Apps" were compiled down to machine code targeted specifically at the Apple iPhone and iPad.[50] This is necessary because the iOS kernel prevents just-in-time compilers from executing on the device.

The Xamarin.iOS stack was made up of:

  • Compilers
    • C# from the Mono Project
    • Third-party compilers like RemObject's Oxygene could target Xamarin.iOS also
  • Core .NET libraries
  • Development SDK:
    • Linker – was used to bundle only the code used in the final application
    • mtouch – the Native compiler and tool used to deploy to the target device
    • Interface Builder integration tools
  • Libraries that bind the native CocoaTouch APIs
  • Xamarin Studio IDE

Xamarin Studio was used as the primary IDE, however additional links to Xcode and the iOS simulator have been written.

From April to early September 2010, the future of MonoTouch was put in doubt as Apple introduced new terms for iPhone developers that prohibited them from developing in languages other than C, C++ and Objective-C, and the use of a middle layer between the iOS platform and iPhone applications. This made the future of MonoTouch, and other technologies such as Unity, uncertain.[51] Then, in September 2010, Apple rescinded this restriction, stating that they were relaxing the language restrictions that they had put in place earlier that year.[52][53]

Version history

[edit]
Release History
Date Version Notes
September 14, 2009 MonoTouch 1.0[54] Initial release
April 5, 2010 MonoTouch 2.0[55] iPad support
April 16, 2010 MonoTouch 3.0[56] iPhone 4 support
April 6, 2011 MonoTouch 4.0[57] iOS 4 support
October 12, 2011 MonoTouch 5.0[58] iOS 5 support
September 19, 2012 MonoTouch 6.0[59] iOS 6 support
February 20, 2013 Xamarin.iOS 6.2[60] Visual Studio support
July 24, 2013 Xamarin.iOS 6.4[61] .NET 4.5 async/await support
June 19, 2013 Xamarin.iOS 7.0[62] XCode 5 and iOS 7 support
September 10, 2014 Xamarin.iOS 8.0[63] iOS 8 and Xcode 6 support
September 16, 2015 Xamarin.iOS 9.0[64] iOS 9 and Xcode 7 support
September 13, 2016 Xamarin.iOS 10.0[65] iOS 10 and Xcode 8 support
September 19, 2017 Xamarin.iOS 11.0[66] iOS 11 and Xcode 9 support
September 14, 2018 Xamarin.iOS 12.0[67] iOS 12 and Xcode 10 support
September 13, 2019 Xamarin.iOS 13.0[68] iOS 13 and Xcode 11 support
September 20, 2020 Xamarin.iOS 14.0[69] iOS 14 and Xcode 12 support

Xamarin.Android

[edit]

Xamarin.Android (formerly known as Mono for Android), initially developed by Novell and continued by Xamarin, was a proprietary[citation needed][70] implementation of Mono for Android-based smart-phones.[71][72][73] It was first released on April 6, 2011.[74] Mono for Android was developed to allow developers to more easily write cross-platform applications that will run on all mobile platforms.[75] In an interview with H-Online, Miguel de Icaza stated, "Our vision is to allow developers to reuse their engine and business logic code across all mobile platforms and swapping out the user interface code for a platform-specific API."[76]

In August 2010, a Microsoft spokesman, Tom Hanrahan of Microsoft's Open Source Technology Centre, stated, in reference to the lawsuit filed by Oracle against Google over Android's use of Java, that "The type of action Oracle is taking against Google over Java is not going to happen. If a .NET port to Android was through Mono it would fall under the Microsoft Community Promise Agreement."[77][78]

The Xamarin.Android stack consisted of the following components:

  • Mono runtime
  • An Android UI designer[79]
  • Libraries:
    • Core .NET class libraries
    • Libraries that bind the native Android/Java APIs
  • SDK tools to package, deploy and debug
  • Xamarin Studio and Visual Studio 2010 integration to design the UI, remotely debug, and deploy.

Mono on macOS

[edit]

CocoaSharp

[edit]

Cocoa# (also known as CocoaSharp) was a bridge framework for Mac OS X, which allowed applications developed with the Mono runtime to access the Cocoa API. It was initially released on August 12, 2004,[80] and was included with the Mono distribution starting with version 1.0.6, released on February 18, 2005.[citation needed] It has not seen any development since 2008,[citation needed] and is now deprecated.[81]

Monobjc

[edit]

Monobjc was CocoaSharp's replacement. It allows .NET developers to use most of the Mac OS X API, including Cocoa, with no native code, while still achieving a native UI.[citation needed]

Xamarin.Mac

[edit]

Xamarin.Mac is a library that allows developers to run .NET and C# apps on the Mac.[82]

License

[edit]

Mono is dual licensed by Xamarin, similar to other products such as Qt and the Mozilla Application Suite. Mono's C# compiler and tools are released under the GNU General Public License (GPLv2 only) (starting with version 2.0 of Mono, the Mono C# compiler source code is also available under the MIT X11 License),[83] the runtime libraries under the GNU Lesser General Public License (LGPLv2 only) and the class libraries under the MIT License. These are all free software and open-source licenses and hence Mono is free and open-source software.

The license of the C# compiler was changed from the GPL to the MIT X11 license[84] to allow the compiler code to be reused in a few instances where the GPL would have prevented such:

  • Mono's Compiler as a Service
    • The Mono interactive Shell
    • The Mono embeddable C# compiler
  • Mono's implementation of the C# 4.0 dynamic binder.
  • MonoDevelop's built-in parser and AST graph

On March 18, 2016, Microsoft's acquisition of Xamarin was officially closed.[85] On March 31, 2016, Microsoft announced at Microsoft Build that they'll completely re-license Mono under the MIT License even in scenarios where previously a commercial license was necessary,[86] and Microsoft stated that they won't assert any "applicable patents" against parties that are "using, selling, offering for sale, importing, or distributing Mono."[87][88] It was also announced that Xamarin had contributed the Mono Project to the .NET Foundation.[87]

Mono and Microsoft's patents

[edit]
This section is an excerpt from Criticism of Microsoft § Mono patent concerns.[edit]

On July 6, 2009, Microsoft announced that it was placing their ECMA 334 and ECMA 335 specifications under their Community Promise pledging that they would not assert their patents against anyone implementing, distributing, or using alternative implementations of .NET.[89] Mono's implementation of those components of the .NET stack not submitted to the ECMA for standardization has been the source of patent violation concerns for much of the life of the project.[90] In particular, discussion has taken place about whether Microsoft could destroy the Mono project through patent suits.[91]

The base technologies submitted to the ECMA, and therefore also the Unix/GNOME-specific parts, are claimed to be safe due to Microsoft's explicitly placing both ECMA 334 (C#) and ECMA 335 (CLI) standards under the Microsoft Community Promise. The concerns primarily relate to technologies developed by Microsoft on top of the .NET Framework, such as ASP.NET, ADO.NET and Windows Forms (see non-standardized namespaces), i.e. parts composing Mono's Windows compatibility stack. These technologies are today[when?] not fully implemented in Mono and not required for developing Mono-applications, they are simply there for developers and users who need full compatibility with the Windows system.

In June 2009 the Ubuntu Technical Board stated that it saw "no reason to exclude Mono or applications based upon it from the archive, or from the default installation set."[92]

The Free Software Foundation's Richard Stallman has stated on June 2, 2009, that "[...] we should discourage people from writing programs in C#. Therefore, we should not include C# implementations in the default installation of GNU/Linux distributions or in their principal ways of installing GNOME".[93] On July 1, 2009, Brett Smith (also from the FSF) stated that "Microsoft's patents are much more dangerous: it's the only major software company that has declared itself the enemy of GNU/Linux and stated its intention to attack our community with patents.", "C# represents a unique threat to us" and "The Community Promise does nothing to change any of this".[94]

Fedora Project Leader Paul Frields has stated, "We do have some serious concerns about Mono and we'll continue to look at it with our legal counsel to see what if any steps are needed on our part", yet "We haven't come to a legal conclusion that is pat enough for us to make the decision to take mono out".[95]

In November 2011 at an Ubuntu Developer Summit, developers voted to have the Mono-based Banshee media player removed from Ubuntu's default installation beginning on Ubuntu 12.04; although reported reasonings included performance issues on ARM architecture, blocking issues on its GTK+ 3 version, and it being, in their opinion, "not well maintained", speculation also surfaced that the decision was also influenced by a desire to remove Mono from the base distribution, as the remaining programs dependent on Mono, gbrainy and Tomboy, were also to be removed. Mono developer Joseph Michael Shields defended the performance of Banshee on ARM, and also the claims that Banshee was not well-maintained as being a "directed personal insult" to one of its major contributors.[96]

Software developed with Mono

[edit]
Banshee media player
GNOME Do

Many programs covering a range of applications have been developed using the Mono application programming interface (API) and C#. Some programs written for the Linux Desktop include Banshee, Beagle, F-Spot, Gbrainy, Docky/GNOME Do, MonoTorrent, Pinta, and Tomboy. The program, Logos 5 Bible Study Software (OS X Version), was written for the MacOS.

A number of video games, such as The Sims 3 and Second Life (for their scripting languages), OpenSimulator virtual world server, or games built with the Unity or MonoGame game engines, also make use of Mono.[97] OpenRA bundles its Apple Disk Image and Linux AppImages with Mono essentially removing almost all dependencies from the game.[98]

Version history

[edit]
Release history[99]
Date Version[100] Notes
June 30, 2004 1.0[101] C# 1.0 support
September 21, 2004 1.1[102]
November 9, 2006 1.2[103] C# 2.0 support
October 6, 2008 2.0[104] Mono's APIs are now in par with .NET 2.0. Introduces the C# 3.0 and Visual Basic 8 compilers. New Mono-specific APIs: Mono.Cecil, Mono.Cairo and Mono.Posix. Gtk# 2.12 is released. The Gendarme verification tool and Mono Linker are introduced.
January 13, 2009 2.2[105] Mono switches its JIT engine to a new internal representation[106] that gives it a performance boost and introduces SIMD support in the Mono.Simd[36] Mono.Simd namespace.
Mono introduces Full Ahead of Time compilation that allows developers to create full static applications and debuts the C# Compiler as a Service[34] and the C# Interactive Shell[35] (C# REPL)
March 30, 2009 2.4[107] This release mostly polishes all the features that shipped in 2.2 and became the foundation for the Long-Term support of Mono in SUSE Linux.
December 15, 2009 2.6[108] The Mono runtime is now able to use LLVM as a code generation backend and this release introduces Mono co-routines, the Mono Soft Debugger and the CoreCLR security system required for Moonlight and other Web-based plugins.
On the class library System.IO.Packaging, WCF client, WCF server, LINQ to SQL debut. The Interactive shell supports auto-completion and the LINQ to SQL supports multiple database backends. The xbuild build system is introduced.
September 22, 2010 2.8[109] Defaults to .NET 4.0 profile, C# 4.0 support, new generational garbage collector, includes Parallel Extensions, WCF Routing, CodeContracts, ASP.NET 4.0, drops the 1.0 profile support; the LLVM engine tuned to support 99.9% of all generated code, runtime selectable llvm and gc; incorporates Dynamic Language Runtime, MEF, ASP.NET MVC2, OData Client open-source code from Microsoft;. Will become release 3.0
February 15, 2011 2.10[110]
October 18, 2012 3.0[111] C# 5.0 support, async support, Async Base Class Library Upgrade and MVC4 - Partial, no async features support.
July 24, 2013 3.2[112] Default Garbage Collector is now the SGEN, instead of Boehm
March 31, 2014 3.4[113]
August 12, 2014 3.6[114]
September 4, 2014 3.8[115]
October 4, 2014 3.10[116]
January 13, 2015 3.12[117]
April 29, 2015 4.0[118] Defaults to .NET 4.5 profile and ships only .NET 4.5 assemblies, defaults to C# 6.0. First release to integrate Microsoft open-source .NET Core code
May 10, 2017 5.0[119] Shipping Roslyn C# compiler to enable C#7 support; Shipping msbuild and deprecating xbuild for better compatibility; Enabling concurrent SGen garbage collector to reduce time spent in GC; Introducing the AppleTLS stack on macOS for HTTPS connections; Continued Progress on .NET Class Library convergence; Updated libjpeg in macOS package
July 14, 2017 5.2[120] Support for .NET Standard 2.0, strong assembly names, and experimental default interface members.
October 5, 2017 5.4[121] The JIT Runtime now supports concurrent method compilation and various other Performance Optimisations; Added .NET 4.7 reference assemblies
February 1, 2018 5.8[122] Initial WebAssembly port; Modes for the SGen GC; Includes Roslyn's csi (C# interactive) REPL tool
February 26, 2018 5.10[123] The Interpreter is now included in the default installation; runtime now supports Default Interface Methods; WebAssembly considered reliable now; Support for .NET 4.7.1 / C# 7.2 / F# 4.1
May 8, 2018 5.12[124] Port to IBM AIX/i; now includes VB.NET compiler; option to use jemalloc
August 7, 2018 5.14[125] Major Windows.Forms update to improve compatibility with .NET
October 8, 2018 5.16[126] Hybrid suspend garbage collector; Client certificate support; C# 7.3 support
December 21, 2018 5.18[127] .NET 4.7.2 support; more CoreFX code is used
April 11, 2019 5.20[128] SSPI (Security Support Provider Interface) in System.Data assembly; Various issues resolved
July 17, 2019 6.0[129] C# compiler defaults to version C# 8.0 RC; Various stability improvement in debugger support; Mono Interpreter is feature complete and stable
September 23, 2019 6.4[130] C# compiler support for C# 8 language version; .NET Standard 2.1 support
December 10, 2019 6.6[131] Added .NET 4.8 reference assemblies
January 15, 2020 6.8[132] Various Bugfixes
May 19, 2020 6.10[133] Various Bugfixes
November 24, 2020 6.12[134] Various Bugfixes
March 4, 2025 6.14[135] First release after transfer to WineHQ

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Mono (software)

View on Grokipedia
from Grokipedia
Mono is an platform that implements Microsoft's .NET Framework, enabling developers to create and execute cross-platform applications compatible with C# and other .NET languages on operating systems including , macOS, and originally Windows. The project provides a (CLR), C# compiler, and class libraries modeled after the ECMA standards for C# and the , facilitating the porting of .NET applications to non-Windows environments without proprietary dependencies. Initiated in 2001 by Miguel de Icaza following Microsoft's announcement of the .NET Framework, Mono aimed to replicate .NET's functionality on Unix-like systems, with early milestones including a self-hosting C# compiler by 2004. Sponsored initially by Ximian and later acquired by Novell in 2003, the project expanded to support mobile development through Xamarin, which leveraged Mono for iOS and Android apps, powering tools like Unity game engine for cross-platform game deployment. After Novell's assets were transferred to Attachmate and Xamarin in 2011, Microsoft acquired Xamarin in 2016, integrating Mono's runtime into the broader .NET ecosystem, though the core Mono project continued independently until its runtime was upstreamed into Microsoft's .NET implementations. Mono's defining characteristics include its emphasis on binary compatibility with .NET Framework where possible, support for ahead-of-time compilation for performance on embedded systems, and extensions like Moonlight for Silverlight compatibility, though it faced scrutiny for incomplete API coverage compared to proprietary .NET. Notable achievements encompass enabling server-side .NET applications on Linux via tools like mod_mono for Apache and fostering mobile and desktop software such as Banshee media player and GNOME Do launcher. The project encountered controversies primarily over potential patent encumbrance, with critics including the arguing that Mono's reliance on Microsoft-patented technologies posed risks to adoption, viewing it as a potential "patent trap" despite Microsoft's community promise not to assert s against individual developers or open-source projects implementing ECMA standards. Microsoft addressed some concerns with a 2009 patent covenant covering implementations of specified .NET standards, but skepticism persisted regarding broader proprietary extensions in Mono, influencing debates on software freedom versus pragmatic .

History

Founding and Early Development

The Mono project originated at Ximian, a company co-founded by and , as an effort to implement an open-source version of Microsoft's .NET Framework, specifically targeting the (CLI) and C# specifications for non-Windows platforms like . De Icaza, already known for co-creating desktop environment, initiated the project following the public release of .NET documentation in December 2000, viewing it as an opportunity to enable cross-platform development with modern languages and tools. The initiative was driven by the goal of fostering a ecosystem compatible with .NET, leveraging ECMA-standardized components to avoid proprietary dependencies. The project was formally announced on June 30, 2001, during de Icaza's presentation at the O'Reilly Open Source Convention (OSCON), where Ximian outlined plans for a runtime, C# compiler, and class libraries to support .NET applications on Unix-like systems. Initial development emphasized rapid prototyping, with a small team including de Icaza focusing on core components. By August 28, 2001, the Mono runtime executed its first "Hello World" program, processing 1821 Common Intermediate Language (CIL) instructions across 12 classes. On September 5, 2001, the self-written C# compiler (mcs) compiled a basic program on Windows using Microsoft's runtime, producing an executable that ran on Linux, demonstrating early cross-platform viability. Subsequent milestones in late 2001 included the release of Mono 0.7 on September 18, providing initial compiler and runtime functionality, and the C# compiler achieving self-compilation on Linux by November 14. Key early contributors comprised Paolo Molaro for runtime optimization, Dietmar Maurer for just-in-time compilation, Dick Porter for class library foundations, and Sergey Lukyanov for metadata handling. By 2002, the compiler advanced to full self-hosting: bootstrapping with the .NET runtime on January 3, operating independently on Linux by March 12, and compiling the core mscorlib library by June 30, marking a foundational step toward a complete, independent .NET-compatible stack under Ximian's stewardship.

Novell Acquisition and Expansion

Novell acquired Ximian, the primary sponsor of the Mono project, on August 4, 2003, for an undisclosed sum, integrating Mono's development into its broader and open-source strategy. This move positioned Mono as a key component for enabling .NET compatibility on , with committing resources to accelerate its maturation into a viable enterprise alternative to Microsoft's .NET Framework. Following the acquisition, expanded Mono's development team from five engineers at Ximian to 20 dedicated staff, fostering contributions from a community of approximately 300 to 400 developers. This investment supported the release of Mono 1.0 on June 30, 2004, marking the project's first stable version with a runtime environment, C# , and core class libraries compliant with ECMA standards. The release emphasized cross-platform , allowing .NET applications to run on while enabling developers to target multiple environments from a single codebase. Under , Mono saw integration into enterprise products, including , with plans announced in 2008 to include Mono 2.0 in 11 for running .NET applications natively on servers. also developed commercial extensions, such as Mono Tools for in 2009, which allowed .NET developers to build and debug Linux-targeted applications within Microsoft's IDE. These efforts prioritized enterprise features like support, enhancing Mono's appeal for porting Windows applications to open-source platforms.

Xamarin and Microsoft Integration

Xamarin was founded in May 2011 by and other former Mono developers following the acquisition of by Attachmate, which discontinued active development of Mono and related projects. The company leveraged the Mono runtime to create cross-platform mobile development tools, including Xamarin.iOS (previously MonoTouch) for applications and Xamarin.Android (previously Mono for Android) for Android, enabling C# and .NET-based app development on non-Windows platforms. These tools used Mono's just-in-time () compiler and ahead-of-time (AOT) compilation to address platform-specific restrictions, such as Apple's ban on on devices. On February 24, 2016, Microsoft announced an agreement to acquire Xamarin, integrating its technology into the Visual Studio ecosystem to enhance cross-platform development for Windows, Android, and iOS. The acquisition positioned Microsoft as the steward of the Mono Project, with Xamarin obtaining a perpetual license to Mono's intellectual property prior to the deal. Post-acquisition, Microsoft relicensed Mono under the MIT License to broaden its adoption and aligned it with emerging .NET initiatives, while making Xamarin tools freely available to reduce barriers for developers. Integration efforts included embedding Xamarin capabilities directly into Visual Studio, such as Xamarin Studio rebranded as announced on November 16, 2016, and improved support for Mono-based workloads in Unity game development. Microsoft's stewardship maintained Mono's role in scenarios requiring full .NET Framework compatibility on and macOS, distinct from the newer cross-platform .NET Core, though development emphasis shifted toward unifying .NET ecosystems. This move facilitated tighter interoperability between Mono-derived mobile tools and Microsoft's cloud services like Azure, while preserving open-source contributions under community governance.

Decline and Transfer to WineHQ

Following the acquisition of Xamarin by Microsoft in February 2016, development focus shifted toward .NET Core, a modular, cross-platform evolution of .NET that rendered the original Mono runtime largely redundant for new applications. Mono's last major upstream release occurred in 2019, after which maintenance stagnated as Microsoft prioritized its dotnet/runtime repository fork for legacy compatibility needs. This transition reflected broader industry movement away from Mono's full-framework emulation toward lightweight, native cross-platform support in .NET 5 and later versions, reducing Mono's relevance for mainstream .NET development. By 2024, Microsoft determined that the upstream Mono project no longer aligned with active development priorities, as most workloads had migrated to modern .NET equivalents. On August 27, 2024, Microsoft announced the donation of the Mono Project to WineHQ, citing synergies with Wine's requirements for executing legacy Windows .NET applications that resist translation to .NET Core due to proprietary or outdated dependencies. Wine, which had long incorporated a Mono variant for .NET interoperability in its Windows compatibility layer, assumed stewardship to sustain support for such edge cases. Under WineHQ's management, the project relocated to GitLab at gitlab.winehq.org/mono/mono, with the first release—version 6.14.0—issued on March 8, 2025, incorporating five years of prior unmerged contributions. This handover ensured continued availability for niche uses, such as Wine's Framework Mono integration, while Microsoft explicitly advised developers to adopt contemporary .NET runtimes over the donated legacy codebase. The move closed a chapter on Mono's role as a pioneering open-source .NET bridge, now preserved primarily for compatibility rather than innovation.

Technical Architecture

Core Runtime Components

The Mono runtime serves as the core execution engine, implementing the ECMA Common Language Infrastructure (CLI) standard (ECMA-335) to provide a virtual machine for running managed code across platforms. It handles just-in-time (JIT) and ahead-of-time (AOT) compilation of Common Intermediate Language (CIL) bytecode into native machine code, automatic memory management via garbage collection, assembly loading, and threading support, enabling compatibility with .NET Framework applications on non-Windows systems. The JIT compiler dynamically translates CIL instructions to optimized native code at runtime, supporting architectures such as x86, x86-64, ARM, and PowerPC, with features like inlining, loop unrolling, and exception handling tailored for performance on diverse hardware. For scenarios requiring reduced startup latency or static linking—such as mobile or embedded deployments—the AOT compiler pre-compiles assemblies into native executables via commands like mono --aot, producing bundles that merge code, libraries, and runtime elements while allowing full static AOT for self-contained binaries. Garbage collection in Mono defaults to the SGen collector in the mono executable, a precise, generational, and compacting mechanism designed for low-latency server and client workloads, which scans and relocates objects to mitigate fragmentation; alternatively, the Boehm conservative collector is available via mono-boehm for conservative root scanning without relocation, though it may introduce higher memory overhead. The runtime's library loader dynamically resolves and loads assemblies, supporting metadata reflection and interoperability with native code through platform invocation (P/Invoke). Threading primitives align with CLI specifications, providing managed threads with synchronization constructs like monitors and mutexes, integrated with host OS threading models. Embedding capabilities allow the runtime to integrate into C/C++ applications, exposing the CLI for scripted extensions while reusing existing native infrastructure, with APIs for initialization, assembly execution, and domain isolation to prevent interference between execution contexts. These components collectively ensure portable, verifiable execution of CLI-compliant code, though Mono's implementation deviates from Microsoft's CLR in optimizations and platform-specific adaptations, such as tailored for in mobile contexts.

Class Libraries and Compatibility

Mono's class libraries form the foundational assemblies that enable application development and execution, mirroring the structure of Microsoft's .NET Framework base class library (BCL) while prioritizing cross-platform portability. The core library, known as mscorlib, provides essential types for basic operations, including collections, threading, and I/O, implemented primarily in C# within the Mono compiler suite (mcs) module. Additional namespaces such as System, System.Collections, System.IO, and System.Threading replicate .NET equivalents, adhering to ECMA-335 standards for the Common Language Infrastructure (CLI) to ensure interoperability. These libraries are organized into assemblies stored in directories corresponding to their namespaces, facilitating modular development and reducing dependencies on platform-specific code. To achieve compatibility, Mono implements profiles that align with various .NET Framework versions, allowing developers to target subsets of the full framework. For instance, Mono's full profile supports most of .NET 4.7 features, encompassing , Entity Framework compatibility layers, and generic collections, but excludes Windows Presentation Foundation (WPF), (WWF), and offers partial support for (WCF) and asynchronous ASP.NET operations. Earlier profiles, such as those emulating .NET 2.0 or 3.5, enable legacy application porting, with Mono providing Unix-specific extensions like interop in assemblies such as System.IO.FileSystem. This profiled approach ensures that CIL assemblies compiled against compatible .NET versions can execute on Mono without recompilation, provided they avoid Windows-exclusive APIs like WinForms or dependencies. Binary compatibility between .NET Framework-compiled libraries and Mono is generally high for pure managed code, as both adhere to the same CLI specification; a library targeting .NET Standard or earlier frameworks will load via Mono's runtime if no Microsoft extensions are invoked. However, discrepancies arise in areas requiring native Windows integrations, such as providers or registry access, where Mono substitutes cross-platform alternatives, potentially leading to behavioral differences verifiable through runtime profiling tools. Post-2014 Microsoft open-sourcing of .NET Core components, Mono incorporated compatible subsets, enhancing alignment with modern .NET Standard libraries up to version 2.1, though full .NET 5+ equivalence remains partial due to Mono's emphasis on Framework-era support. Developers can verify compatibility using Mono's mcs compiler flags for specific profiles or tools like mono --verify to detect assembly mismatches.

Execution Engines and Optimizations

Mono employs a just-in-time (JIT) compiler as its core execution engine, translating (CIL) bytecode from .NET assemblies into native at runtime to enable platform-specific execution. This JIT supports multiple architectures, including x86, , and PowerPC, and operates with configurable optimization levels such as -O=all to enable comprehensive passes like inlining and . In addition to JIT, Mono provides ahead-of-time (AOT) compilation, which precompiles assemblies into native code artifacts—such as ELF shared objects on systems—stored alongside the original files (e.g., assembly.exe.so). The runtime loads these AOT images preferentially over compilation for available methods, reducing initial JIT overhead and enabling code sharing via (PIC) mapped with , though PIC incurs a minor performance penalty relative to non-PIC JIT output. AOT integrates with the JIT in hybrid modes, where unloaded or dynamically generated methods fall back to JIT, but full AOT (--full-aot) disables JIT entirely to comply with runtime restrictions on platforms like iOS, precomputing elements like generic virtual tables to minimize metadata processing. This mode supports platforms limited to x86, AMD64, and ARM, but restricts features requiring dynamic code emission, such as Reflection.Emit or certain LINQ expressions. Optimizations in both engines include high-level intermediate representation (IR) transformations, loop unrolling, and dead code elimination, with AOT allowing additional passes not feasible in standard JIT due to precompilation, such as full program analysis when combined with profile-guided data. Mono can leverage the LLVM backend for enhanced code generation and optimization in JIT or AOT scenarios via flags like --llvm, improving instruction selection and vectorization on supported hardware. Profile-guided optimization profiles execution to prioritize hot paths, further tuning code layout and inlining decisions.

Differences from Microsoft's .NET

Mono implements the ECMA-334 standard for C# and ECMA-335 for the (CLI), enabling binary compatibility with .NET Framework assemblies up to version 4.7, but excludes Windows-specific components such as Windows Presentation Foundation (WPF), (WWF), and provides only limited support for Windows Communication Foundation (WCF) and asynchronous features. In contrast, Microsoft's .NET Framework incorporates proprietary extensions beyond these ECMA standards, with deep integration into Windows APIs for desktop technologies like WPF and full WCF functionality optimized for Windows environments. The runtime engines diverge significantly: Mono employs its own JIT compiler, which supports a lightweight "mini JIT" for rapid startup or an LLVM-based backend for advanced optimizations, alongside Boehm-Demers-Weiser garbage collection tailored for multi-platform use. Microsoft's .NET implementations use RyuJIT in the CoreCLR runtime (for .NET Core/5+), which features tiered compilation, aggressive inlining, SIMD vectorization, and profile-guided optimizations, often yielding superior performance in benchmarks compared to Mono's engine, particularly for compute-intensive workloads. Mono's design emphasizes a minimal footprint and ahead-of-time (AOT) compilation for scenarios like mobile and embedded devices, where .NET's runtime may require additional configuration for similar deployments. Class libraries in Mono are independent re-implementations of core namespaces (e.g., mscorlib, System, System.Data), achieving compatibility with .NET Standard across all versions and allowing most portable .NET Framework code to run without modification on non-Windows platforms, provided it avoids Windows-exclusive APIs. However, gaps persist in proprietary or platform-dependent areas, such as incomplete emulation of Windows registry access or Active Directory integration, necessitating alternatives like Gtk# for UI or custom providers for data access. Microsoft's .NET libraries, especially in the modern unified .NET platform, include updated, high-performance implementations with broader ecosystem support, including native AOT for reduced startup times and container optimization, which Mono approximates but does not fully match in feature parity or ongoing innovation. Both projects share MIT licensing under the .NET Foundation since Microsoft's acquisition of in 2016, but Mono's independent origins enable community-driven extensions for niche uses like Unity scripting, while Microsoft's .NET prioritizes enterprise-scale cloud and web scenarios with official tooling and security updates. Historically, Mono faced scrutiny over potential risks from Microsoft's .NET elements, mitigated by a 2009 community promise not to assert patents against implementers, though this did not cover all extensions.

Development Tools and Ecosystem

IDEs and Editors

MonoDevelop served as the primary (IDE) for Mono, initially released in 2005 as a GNOME-oriented IDE built on the Mono runtime and GTK#, supporting C#, , and cross-platform .NET application development on , Windows, and macOS. It featured , refactoring tools, integrated debugging with the Mono runtime, and graphical designers for WinForms and GTK# interfaces. Over time, MonoDevelop evolved through acquisitions: rebranded as Xamarin Studio in 2013 following 's involvement in mobile development, and later integrated into for Mac in 2016 after Microsoft's acquisition of Xamarin, retaining core Mono compatibility for building and debugging. However, the original MonoDevelop project ceased active maintenance around 2020, with its GitHub repository abandoned by earlier that year. Visual Studio for Mac, which inherited MonoDevelop's codebase, provided enhanced Mono support including workload templates for console, GUI, and web apps, but shifted toward .NET Core/.NET 6 by 2022, reducing reliance on the Mono framework. Microsoft retired Visual Studio for Mac entirely on August 31, 2024, recommending alternatives like or for cross-platform .NET tasks. In contemporary Mono workflows, particularly for legacy projects or embedded uses like Unity (which embeds Mono), Visual Studio Code with the official C# extension (powered by OmniSharp and Roslyn) is widely adopted, offering IntelliSense, debugging, and build integration directly with the Mono runtime on Linux, macOS, and Windows. This setup supports Mono-specific compilation via mcs or mono commands while providing language server protocol features for code navigation and error detection. General-purpose editors such as Vim or can handle Mono development through plugins for C# syntax highlighting, OmniSharp integration for autocompletion, and shell integration for invoking Mono tools like mkbundle for standalone executables, though they lack the full IDE debugging and project management of dedicated environments. Rider offers another robust option with native support for Mono projects, including runtime selection and cross-platform profiling, suitable for professional development despite not being Mono-exclusive.

Mobile and Cross-Platform Frameworks

Mono's contributions to mobile development originated with MonoTouch, released in 2010, which provided an implementation of the Mono runtime for iOS devices, enabling C# applications to access native iOS APIs while adhering to Apple's ahead-of-time (AOT) compilation requirements due to restrictions on just-in-time (JIT) execution in App Store apps. Similarly, Mono for Android, introduced in 2011, integrated the Mono runtime with the Android platform, allowing managed code to run alongside the Android Runtime (ART) and interact with native Java-based APIs through bindings. These tools formed the foundation for cross-platform mobile app development by permitting code reuse across iOS and Android while generating native performance applications. In 2012, these efforts evolved into the platform, which rebranded MonoTouch as Xamarin.iOS and Mono for Android as Xamarin.Android, unifying them under a shared C# codebase for building mobile apps with access to platform-specific features. Xamarin.Android specifically embeds a shared Mono runtime instance for and deployment, supporting both and AOT modes to optimize for device constraints. This architecture allowed up to 90% code sharing between platforms, reducing development time compared to separate native implementations in /Swift for and /Kotlin for Android. Xamarin.Forms, introduced in 2014, extended Mono's cross-platform capabilities by providing a declarative UI framework for shared user interfaces across , Android, and later Windows, abstracting platform differences while leveraging the underlying Mono runtime for execution. Following Microsoft's 2016 acquisition of , these frameworks integrated deeper into the .NET ecosystem, influencing subsequent tools like .NET , though Mono's runtime remained integral to Xamarin-based deployments until broader .NET unification efforts. Frameworks such as MvvmCross, built atop , further utilized Mono for model-view-viewmodel (MVVM) patterns in cross-platform apps, demonstrating its versatility beyond core Xamarin tooling. Microsoft's .NET implementation, encompassing .NET Core and subsequent unified versions from .NET 5 onward, evolved as a cross-platform successor incorporating Mono's contributions for non-Windows environments, including shared runtime components like garbage collection and compilation. The dotnet/runtime repository maintains a of Mono's , integrating it into the broader .NET ecosystem for workloads requiring legacy .NET Framework compatibility on and other platforms. In August 2024, transferred stewardship of the original Mono project to WineHQ, enabling enhanced .NET Framework support within Wine for executing Windows-specific .NET applications on without native porting. This aligns with Mono's historical role in bridging proprietary technologies to open-source systems, though now directs developers toward .NET for new projects. Key projects leveraging Mono include Unity, which employs a customized of the Mono runtime as its default scripting backend for C# code execution across game consoles, desktops, and mobile devices, prioritizing embeddability and . Another is , an open-source Silverlight runtime developed by the Mono team to run Silverlight 1.0 through 4.0 content on systems, though it is no longer actively maintained. These efforts highlight Mono's influence on cross-platform media and game development tools prior to .NET's maturation.

Platform Support and Deployment

Linux and Unix-like Systems

Mono has provided robust support for Linux and Unix-like systems since its inception in 2001, serving as a primary platform for running .NET Framework-compatible applications outside Windows. The runtime accommodates 32-bit and 64-bit architectures, including x86, , ARMv7, ARM64, and MIPS, across major distributions such as , , , , RHEL derivatives like and , and BSD variants. This enables cross-compilation and execution of C# and other CLI languages on POSIX-compliant environments, with adaptations for Unix file systems, signals, and threading models distinct from Windows NT kernel behaviors. Installation on Linux distributions follows repository-based methods for stability and updates. Users add the Mono project's GPG key and repository to their package manager—for instance, on 20.04 or later, executing sudo apt install gnupg ca-certificates followed by repository addition and sudo apt install mono-complete installs the full runtime, class libraries, and tools as of the latest stable release (Mono 6.12.0 as of April 2021, with maintenance updates). On RPM-based systems like or RHEL 8/9, sudo dnf install mono-complete after enabling the repository achieves similar results, ensuring dependency resolution via native package ecosystems. Source compilation is also supported for custom builds, requiring GCC or , autotools, and dependencies like libgdiplus for graphics. Deployment of Mono applications on emphasizes self-contained binaries or shared runtime installations to minimize dependencies. .NET assemblies compiled on Windows or other platforms run directly via the mono executable, maintaining binary compatibility for CLI metadata and IL , though Unix path separators (/) and case-sensitive file handling require code adjustments for portability. Server applications, such as sites via XSP or with Mono's mod_mono, leverage Linux's and scalability, with tools like mkbundle bundling assemblies into native executables for distribution without requiring Mono installation on target systems. Limitations persist in Windows-specific APIs, such as full WMI or COM interop, necessitating P/Invoke wrappers for Unix native libraries like libc or libpthread. Performance on Linux benefits from Mono's just-in-time compiler optimizations, including via Full AOT for embedded or high-throughput scenarios, and garbage collection tuned for Unix . Empirical benchmarks show near-parity with .NET Framework on Windows for compute-bound tasks, though I/O-heavy operations may vary due to underlying kernel differences. Mono's integration with for service management and containerization tools like Docker facilitates production deployments, as seen in legacy .NET migrations to servers.

macOS and iOS Integration

Mono provides runtime support for executing .NET applications on macOS versions 10.9 (Mavericks) and later, enabling the development and deployment of server, console, and graphical user interface (GUI) applications. This integration leverages the Mono runtime to compile and run Common Language Runtime (CLR)-compatible code natively on Apple's operating system, with installation available via official packages that include the necessary frameworks. For native macOS application development, MonoMac offers C# bindings to the Cocoa application programming interfaces (APIs), allowing developers to build applications that interface directly with macOS system components using Mono as the underlying runtime. Tools such as MonoMacPackager facilitate the creation of standard macOS application bundles (.app files) from Mono-based projects, ensuring compatibility with Apple's packaging conventions. Additionally, integrated development environments like MonoDevelop (now evolved into Xamarin Studio and further into Visual Studio for Mac) support .NET development workflows on macOS, including debugging and project management tailored to the platform. On iOS, Mono's integration occurs primarily through the Xamarin.iOS framework, an extension of the Mono runtime optimized for Apple's mobile ecosystem, including iOS, tvOS, and watchOS. Xamarin.iOS, originally developed as MonoTouch in 2010, compiles C# code ahead-of-time (AOT) into native ARM machine code, providing access to iOS-native APIs while adhering to Apple's restrictions on dynamic code generation. This approach enables cross-platform .NET applications to run as fully native iOS binaries, with historical version releases aligning key updates to iOS milestones, such as Xamarin.iOS 6.0 supporting iOS 6 in September 2012 and Xamarin.iOS 7.0 adding iOS 7 compatibility in June 2013. Xamarin, founded in May 2011 by Mono's original engineers, formalized this integration, evolving MonoTouch into a commercial product before its acquisition by Microsoft in 2016, after which it transitioned toward unified .NET tooling while retaining Mono's core runtime elements.

Android and Embedded Devices

Mono's runtime has been ported to the Android operating system, enabling the execution of managed .NET code on mobile devices. The Xamarin.Android framework, an extension of Mono, provides developers with bindings to native Android APIs, allowing C# applications to interact with device hardware and services such as sensors, cameras, and location services. This implementation uses a customized Mono runtime with just-in-time (JIT) compilation optimized for Android's Dalvik/ART environments, including ahead-of-time (AOT) compilation options for improved startup times and reduced memory footprint. Xamarin.Android, initially released in 2011 as Mono for Android, facilitated cross-platform development by compiling managed assemblies into native code packages deployable via Android Package Kit (APK) files. However, discontinued official support for Xamarin.Android on May 1, 2024, recommending migration to .NET Multi-platform App UI () for ongoing Android development. The open-source Mono runtime nonetheless remains embeddable for custom Android applications, though compatibility with newer Android versions (e.g., API level 34+) may require manual updates. For embedded devices, Mono supports runtime embedding into native C or C++ applications, enabling managed code execution in resource-constrained environments like ARM-based systems or IoT hardware. Developers initialize the runtime using mono_jit_init to load assemblies, invoke C# methods from native code via mono_runtime_invoke, and expose native functions to managed code through platform invocation (P/Invoke). This approach minimizes overhead by statically linking libmono and configuring domain-specific settings, such as assembly search paths with mono_set_dirs, making it viable for embedded Linux distributions. Embedding Mono has been demonstrated on embedded Linux systems since at least 2009, supporting scenarios like scripting interfaces, dynamic extensions, or lightweight web services without full .NET Framework dependencies. Official samples illustrate use cases such as evaluating C# expressions from C hosts or integrating managed GUIs, with optimizations for low-memory profiles via Boehm or Sgen garbage collectors. While not tied to specific commercial embedded products in , this capability has informed hybrid applications in set-top boxes and networked devices requiring extensible logic.

Managed vs. Unmanaged Code Handling

Mono executes managed code, compiled to Common Language Infrastructure (CLI) intermediate language (IL), through its runtime environment, which provides just-in-time (JIT) compilation, garbage collection via the SGen or Boehm collectors, and services like type safety and exception handling. This aligns with the ECMA-335 standard for the Common Language Runtime (CLR), ensuring that managed assemblies run portably across supported platforms without direct hardware access. In contrast, unmanaged code, such as native C or C++ binaries, is not executed directly by the Mono runtime; instead, interoperability occurs primarily through Platform Invocation Services (P/Invoke), enabling managed C# code to declare and call functions from shared libraries or DLLs. The runtime handles marshaling of data types between managed objects and unmanaged pointers, including automatic pinning of managed memory to prevent garbage collection interference during native calls, though developers must avoid retaining unmanaged references to managed memory post-call to prevent crashes or leaks. Mono supports mixed-mode assemblies—containing both managed IL and unmanaged native code, often produced by Managed C++—but this is limited to Windows platforms due to dependencies on the Windows PE format and loader. On non-Windows systems, such assemblies require separation, with unmanaged portions extracted or handled via P/Invoke. For scenarios embedding Mono in unmanaged applications, the runtime can be initialized from C/C++ hosts to invoke managed methods, facilitating hybrid scenarios like game engines calling into scripted logic. Performance considerations arise in unmanaged interactions: P/Invoke incurs overhead from marshaling and thunk generation, though Mono optimizes with custom trampolines for repeated calls. Unlike fully managed execution, unmanaged code bypasses Mono's safety features, exposing risks like buffer overflows or manual memory management, which developers must mitigate explicitly. Mono's removal of legacy features like DllMap configuration in later versions (post-.NET 5 compatibility) streamlines native library loading but reduces flexibility for platform remapping.

License History and Terms

The Mono project's class libraries were initially licensed under the GNU Lesser General Public License (LGPL), with the runtime under the GNU General Public License (GPL). On January 28, 2002, the class libraries were relicensed to the permissive MIT X11 license to facilitate broader adoption and compatibility with proprietary software. Prior to 2016, the Mono runtime and associated tools remained under the GPL, which imposed requirements on derivative works. On March 31, 2016, following Microsoft's acquisition of (the steward of Mono since Novell's 2011 sale), the runtime, compilers, tools, and remaining components were relicensed to the , aligning the entire project under a single permissive terms to encourage integration with the emerging .NET ecosystem. Under current terms, the Mono runtime, C# (including the mcs and csc variants), tools, and most class libraries are distributed under the , permitting commercial use, modification, and redistribution with minimal restrictions beyond retaining the license notice. Exceptions include select runtime components under the BSD license and certain class libraries under the 2.0; a complete enumeration is provided in the project's LICENSE file. Contributions are governed by the .NET Foundation Contributor License Agreement (CLA), ensuring compatibility with MIT terms. This structure allows proprietary applications to link against Mono without triggering obligations.

Microsoft Patent Covenants

In July 2009, extended its Community Promise to cover implementations of the ECMA-334 standard for C# and ECMA-335 for the (CLI), providing a covenant not to assert any "Applicable Patents" against parties making, using, selling, offering for sale, importing, or distributing conforming implementations. This pledge applied specifically to Mono as an open-source CLI implementation, addressing prior uncertainties for non-Novell users following the -Novell agreement, which had limited patent indemnification to Novell's paying customers. The covenant defines "Applicable Patents" as those deems essential to the ECMA standards, irrevocably promising non-assertion provided the implementation adheres to the specifications without extension or modification that introduces new claims. It excludes patents on non-standard features, such as certain Microsoft-specific extensions not submitted to ECMA, leaving potential exposure for Mono components incorporating proprietary elements. Critics, including the , argued the promise contained loopholes, such as its limitation to ECMA-covered portions and lack of coverage for Microsoft's broader .NET patent portfolio, potentially rendering it insufficient to eliminate risks for full Mono adoption in projects. Proponents, including Mono maintainers, viewed it as a sufficient safeguard for standard-compliant usage, enabling continued development without imminent legal threats from . No lawsuits from against Mono implementers have materialized under this framework as of 2025.

Controversies and Free Software Criticisms

The Free Software Foundation (FSF), through statements by founder Richard Stallman, has criticized Mono for encouraging dependence on C#, a language tied to Microsoft's proprietary .NET ecosystem, arguing that this introduces unnecessary patent risks to free software projects. In a June 25, 2009, FSF bulletin, Stallman warned that Microsoft, holding numerous software patents, could strategically enforce them against free C# implementations like Mono to suppress competition, potentially driving such projects "underground" while proprietary .NET remains unaffected. He described reliance on Mono as a "gratuitous risk," urging developers to prioritize alternatives like Java or native toolkits to avoid entrenching Microsoft's intellectual property influence in free software distributions. A core concern centered on Mono's implementation of non-ECMA-standardized .NET components, such as Windows Forms (WinForms), which critics contended infringe undisclosed Microsoft patents not covered by the company's October 2006 patent covenant with Novell. The 2006 Novell-Microsoft agreement, involving a $348 million payment from Novell for patent protection covering SUSE Linux users and Mono contributors, was decried by free software advocates as legitimizing Microsoft's patent aggression against Linux, with limited benefits extending only to Novell customers and not the broader Mono community. FSF Europe president Georg Greve highlighted in 2011 that this deal fragmented the free software ecosystem, exposing non-Novell Mono users to litigation risks without reciprocal protections. Microsoft's July 2009 extension of its Community Promise to ECMA standards, intended to shield open-source .NET implementations, was dismissed by the FSF as insufficient and self-serving, given Microsoft's of assertions against free software like and its to all relevant patents. Stallman reiterated in 2009 that such promises from a company positioning itself as an adversary to GNU/ offered no reliable safeguard, potentially luring developers into adopting patent-encumbered technologies under false security. These critiques extended to distribution policies, with Stallman opposing Debian's default inclusion of Mono in 2009, viewing it as a vector for systemic patent vulnerability in free operating systems. Beyond patents, free software purists faulted Mono for fostering cultural and technical lock-in to Microsoft paradigms, diverting resources from fully libre alternatives and mirroring proprietary dependencies in open ecosystems. Proponents like Mono founder Miguel de Icaza countered that ECMA standardization and community contributions mitigated risks, but skeptics, including Stallman, maintained that voluntary adoption of C# undermined the free software movement's independence from corporate-controlled standards. No Microsoft patent suits against Mono materialized by 2025, yet the episode underscored ongoing tensions between pragmatic cross-platform development and ideological commitments to patent-free software purity.

Adoption, Impact, and Criticisms

Notable Applications and Users

Banshee, a cross-platform media player developed using Mono, Gtk#, and GStreamer, provided music management and playback capabilities integrated into GNOME desktops and served as the default player in Ubuntu 10.10 through 11.04. Its reliance on Mono enabled efficient handling of multimedia tasks on Linux systems, with the project reaching version 2.6.2 in February 2014. Unity Technologies utilizes a forked version of the Mono runtime as the default scripting backend in the Unity game engine, supporting C# script execution through just-in-time compilation for cross-platform game development on desktops, mobiles, and consoles. This integration has powered millions of games and applications, though Unity has introduced alternatives like IL2CPP for improved performance in recent versions. Xamarin, leveraging Mono as its core runtime, enabled developers to build native iOS and Android applications in C# and other .NET languages, abstracting platform-specific APIs while compiling to native code. Acquired by Microsoft in 2016, Xamarin powered numerous mobile apps before evolving into .NET MAUI, with Mono handling execution on non-Windows environments during its active period. Other notable Mono-based applications include GNOME Do, a productivity launcher for quick application access and task execution within GNOME, and Plastic SCM, a version control system employed by development teams for source code management. These examples highlight Mono's role in facilitating desktop and developer tools on Linux and Unix-like systems.

Technical Advantages and Achievements

Mono provides a just-in-time (JIT) compiler and ahead-of-time (AOT) compilation capabilities, enabling efficient execution of managed code across diverse architectures including x86, x86-64, ARM, and PowerPC. Its runtime includes automatic memory management via garbage collection, reflection, generics, and threading support, which facilitate higher-level programming while maintaining compatibility with ECMA standards for C# and the Common Language Infrastructure (CLI). A key achievement is its high degree of compatibility with the .NET Framework, supporting up to .NET 4.7 for most features excluding Windows Presentation Foundation (WPF), Windows Workflow Foundation (WWF), and with partial support for Windows Communication Foundation (WCF) and asynchronous ASP.NET operations; this allows many Microsoft .NET binaries to run without recompilation on non-Windows platforms. The SGen garbage collector represents a significant innovation, employing generational collection strategies that separate nursery (new objects) from old generations, reducing pause times and improving throughput for server and real-time workloads compared to traditional conservative scanners like Boehm's GC used in earlier versions. Mono's class libraries extend beyond Microsoft's with platform-specific integrations such as Gtk+, OpenGL, Cairo, and POSIX APIs, enhancing cross-platform development for Linux, macOS, BSD, embedded systems like Android and iOS, and even gaming consoles such as Wii and PlayStation 3. In benchmarks, Mono has demonstrated performance exceeding native compiled code in certain scenarios and occasionally surpassing Microsoft's .NET runtime, attributed to optimizations in JIT and GC handling.

Limitations and Performance Critiques

Mono has historically faced compatibility challenges with the full Microsoft .NET Framework, supporting most features up to .NET 4.7 but excluding Windows Presentation Foundation (WPF), Windows Workflow Foundation (WWF), and offering only limited support for Windows Communication Foundation (WCF) and asynchronous ASP.NET components. This partial alignment has required developers to modify code or avoid certain APIs when porting applications, as Mono's implementation prioritizes cross-platform functionality over exact behavioral parity with Microsoft's runtime. For instance, ASP.NET Core versions beyond early iterations lack official support on Mono, pushing users toward Microsoft's .NET Core runtime for modern web workloads. Performance critiques often highlight Mono's runtime lagging behind Microsoft's CoreCLR, particularly in compute-intensive tasks. Benchmarks have shown Mono's Common Language Runtime (CLR) executing 3-4 times slower than CoreCLR for operations like hash computations, attributed to differences in just-in-time (JIT) compilation and optimization strategies. While Mono can outperform .NET in isolated scenarios, such as certain I/O-bound operations, aggregated tests in distributed processing and general workloads indicate Microsoft .NET delivering higher throughput and lower latency overall. These gaps stem from Mono's Boehm-Demers-Weiser garbage collector (GC), which is conservative and prone to longer pause times compared to the server GC in .NET Framework or the generational improvements in CoreCLR. Garbage collection in Mono has drawn specific criticism for non-determinism and interference with real-time or latency-sensitive applications. The conservative GC scans stack roots imprecisely, potentially inflating memory pressure and causing unpredictable stalls, especially in scenarios involving unmanaged threads where collection halts execution without concurrent support. Unlike Microsoft's evolving GC modes, which include background and concurrent options for reduced pauses, Mono's implementation has historically prioritized simplicity over advanced heuristics, leading to critiques in embedded or game development contexts where consistent frame rates are critical. Despite optimizations like LLVM-backed JIT enhancements yielding up to 2.3x gains in floating-point code as of 2018, these do not fully bridge the gap to native .NET performance on Windows. As Microsoft's .NET unified platform advanced post-2016, Mono's role diminished, with critics noting its maintenance focused on legacy compatibility rather than incorporating cutting-edge features like tiered compilation or hardware intrinsics, rendering it less suitable for high-performance, modern .NET applications. This has prompted migrations away from Mono in favor of official cross-platform .NET, underscoring its limitations in scalability and optimization depth.

Community and Industry Reception

The open-source developer community initially embraced Mono for enabling .NET Framework compatibility on non-Windows platforms, with early adopters at events like the 2005 Professional Developers Conference expressing enthusiasm for its potential in Linux certification and cross-platform deployment. However, reception grew polarized, particularly among free software advocates wary of Microsoft's intellectual property influence; critics argued that reliance on C# and Mono could expose users to patent litigation risks, despite Microsoft's Community Promise covering ECMA-standardized portions since 2009. The Free Software Foundation formally cautioned against depending on Mono or C# in June 2009, emphasizing that while free C# implementations aid platform portability, they risk entrenching non-free dependencies and undermining GNU/Linux independence. Miguel de Icaza, Mono's founder, encountered significant backlash within free software circles, with detractors labeling the project as a vector for Microsoft encroachment and contributing to his marginalization from FOSS events and discourse by the mid-2000s. Ubuntu founder Mark Shuttleworth downplayed acute patent threats in 2008, noting broader risks across Ubuntu components but affirming no immediate Mono-specific issues at the time. Despite such divisions, practical developer communities sustained contributions via GitHub, with Mono's repository maintaining over 2,200 open issues and active pull requests as of recent activity, reflecting ongoing utility in legacy and niche cross-platform scenarios. In industry contexts, Mono garnered adoption for its role in bridging .NET to Linux and embedded systems, powering tools like Xamarin for mobile development (acquired by Microsoft in 2016) and serving as the runtime for Unity Technologies' game engine, which shipped millions of titles across platforms. Analysts at RedMonk highlighted Mono's appeal in combining Microsoft development tools with Linux deployment flexibility, fostering uptake among enterprise Linux vendors by the mid-2000s. By 2011, publications like SD Times urged Microsoft to bolster Mono amid Novell's acquisition uncertainties, underscoring its perceived value despite limited direct corporate endorsement. More recently, Microsoft's August 2024 donation of Mono to the Wine project signals sustained industry recognition of its compatibility layer for Windows applications on Linux, even as .NET's evolution toward unified cross-platform runtimes diminished its centrality.

Current Status and Future Outlook

Development Activity Post-2019

Following the release of Mono 6.0 in September 2019, which introduced improvements such as better support for .NET Standard 2.1 and enhanced garbage collection, the Mono Project shifted to maintenance mode with no further major releases. Minor patch releases continued sporadically to address security vulnerabilities and critical bugs, with the final patch, version 6.12.0.206, issued in February 2024. These updates focused on stability rather than new features, reflecting the project's reduced upstream development as resources pivoted toward Microsoft's .NET ecosystem. In August 2024, Microsoft transferred stewardship of the Mono Project to the WineHQ organization, which maintains Mono as a component for running Windows .NET applications on Linux via Wine. This handover included the upstream source code repository, now hosted at gitlab.winehq.org/wine-mono/mono, allowing Wine to continue targeted maintenance for compatibility needs. Meanwhile, Microsoft has sustained active development of a Mono runtime fork within the dotnet/runtime repository, integrating it into .NET 8 and later versions to support legacy workloads and specific platforms like iOS and Android via Xamarin and .NET MAUI. The original Mono GitHub repository (github.com/mono/mono) saw minimal commits post-2019, primarily for patches, with plans to archive it after providing binaries for up to four years from the last release. Project maintainers have recommended migrating applications to the unified .NET platform, citing completed compatibility efforts that render standalone Mono largely obsolete for new development. This transition underscores Mono's evolution from a primary cross-platform runtime to a specialized legacy tool, with ongoing but niche activity under WineHQ and Microsoft's fork.

Integration with Modern .NET Ecosystem

As part of the .NET platform unification announced in May 2019 and realized with the .NET 5 release in November 2020, Mono's cross-platform runtime components and innovations were incorporated into the core .NET runtime to enable a single, unified framework supporting Windows, Linux, macOS, Android, and iOS. This integration drew from Mono's longstanding expertise in non-Windows environments, including its ahead-of-time (AOT) compilation capabilities and mobile-specific optimizations, which complemented .NET Core's just-in-time (JIT) focus to address platform-specific constraints like iOS's prohibition on JIT execution. The resulting dotnet/runtime repository now hosts a modernized fork of the Mono runtime, where Microsoft has migrated legacy Mono workloads, completing this transition by 2023 to streamline development under a cohesive ecosystem. In mobile and embedded scenarios, Mono remains embedded within the modern .NET stack, particularly through successors to Xamarin. .NET MAUI, released in May 2022 as an evolution of Xamarin.Forms, relies on Mono-derived runtimes for Android and iOS targets to handle AOT compilation and native interoperability, ensuring compliance with platform restrictions while leveraging .NET's unified libraries and tooling. For instance, Mono's interpreter mode in .NET MAUI for iOS and Mac Catalyst, introduced to bypass certain AOT limitations, allows dynamic code interpretation at runtime for select app components, though it incurs performance overhead compared to fully compiled execution. This selective retention preserves Mono's value for scenarios requiring fine-grained control over native APIs, such as in Xamarin.Android, where the Mono runtime provides the foundational execution environment. Despite these integrations, Mono's role has contracted as the unified .NET runtime (.NET 6 and later) achieves native cross-platform parity without relying on Mono as a separate entity for most server, desktop, and cloud workloads. In August 2024, Microsoft donated the original Mono project repository to WineHQ, signaling that general-purpose Mono maintenance is no longer prioritized internally, with developers encouraged to adopt the dotnet/runtime fork for ongoing needs. This shift reflects .NET's maturation, where Mono's historical contributions—such as pioneering .NET on Linux and mobile—have been absorbed, reducing fragmentation while sustaining specialized support through maintained forks.

Legacy Role in Cross-Platform Development

Mono emerged in 2001 as an independent effort to implement Microsoft's .NET Framework on Linux and other non-Windows platforms, enabling developers to target multiple operating systems with C# and related languages without platform-specific rewrites. Its initial stable release on June 30, 2004, provided a runtime and class libraries compatible with much of the .NET ecosystem, filling a gap left by Microsoft's Windows-centric focus at the time. This allowed early adoption for server applications, desktop tools, and embedded systems on Linux distributions, demonstrating the feasibility of "write once, run anywhere" for .NET code years before Microsoft's official cross-platform initiatives. The project's runtime powered influential cross-platform tools and applications, notably serving as the foundation for Unity's C# scripting since its early versions around 2005, which facilitated game development deployable to Windows, macOS, Linux, consoles, and mobile devices from a single codebase. Similarly, Xamarin, launched in 2011 and built atop Mono, enabled shared C# codebases for iOS and Android apps, reducing development friction for mobile cross-platform work and influencing later frameworks like .NET MAUI. These uses highlighted Mono's practical role in bridging proprietary ecosystems, with thousands of applications ported or natively built for Linux via its compatibility stacks for ASP.NET and Windows Forms. Mono's independent evolution influenced Microsoft's shift toward cross-platform .NET, as its open-source contributions—such as runtime optimizations and non-Windows porting expertise—informed .NET Core's architecture starting in 2014, with Mono 4.0 in 2015 incorporating early .NET Core components for bidirectional compatibility. Following Microsoft's acquisition of Xamarin in February 2016, elements of Mono were relicensed under MIT and integrated into the broader .NET runtime, underscoring its foundational proof-of-concept for modular, OS-agnostic .NET deployment. Despite .NET Core supplanting much of Mono's role by 2016, the project sustained legacy applications in niches like embedded devices and compatibility layers, preserving cross-platform viability for codebases predating unified .NET platforms.

References

  1. https://www.mono-project.com/
  2. https://www.mono-project.com/docs/about-mono/
  3. https://github.com/mono/mono
  4. https://www.mono-project.com/docs/about-mono/history/
  5. https://docs.lextudio.com/blog/mono-project-history-future-analysis/
  6. https://tirania.org/blog//archive/2014/Nov.html
  7. https://www.mono-project.com/news/
  8. https://dotnetcore.show/episode-6-but-what-is-mono/
  9. https://www.microfocus.com/documentation/edirectory-developer-documentation/mono-project/
  10. https://mono.fandom.com/wiki/Software_using_Mono
  11. https://www.fsf.org/news/2009-07-mscp-mono
  12. https://askubuntu.com/questions/10209/why-is-mono-so-controversial
  13. https://arstechnica.com/information-technology/2009/07/microsoft-issues-patent-promise-dispels-mono-concerns/
  14. https://www.mono-project.com/docs/about-mono/concerns-about-mono/
  15. https://winaero.com/microsoft-delegates-mono-project-development-to-wine-community/
  16. https://mono.github.io/mail-archives/mono-list/2003-October/016345.html
  17. https://docs.lextudio.com/blog/brief-history-of-monodevelop-93b1d4011978
  18. https://www.computerworld.com/article/1717897/novell-buys-ximian.html
  19. https://www.zdnet.com/article/novell-acquires-ximian/
  20. https://s3.us.cloud-object-storage.appdomain.cloud/res-files/333-Molaro.pdf
  21. https://www.mono-project.com/docs/about-mono/releases/1.0.0/
  22. https://www.suse.com/es-es/news-articles/2004/06/mono/
  23. https://www.suse.com/de-de/news-articles/2008/03/novell-announces-development-plans-for-suse-linux-enterprise-11/
  24. https://www.suse.com/pt-br/news-articles/2009/11/novell-delivers-first-commercial-solution-to-build-net-applications-for-linux-with-microsoft-visual-studio/
  25. https://docs.lextudio.com/blog/the-end-of-mono
  26. https://www.itwriting.com/blog/4666-the-strategy-behind-mono-has-shifted-ten-years-of-open-source-net.html
  27. https://www.oreilly.com/library/view/mobile-devops/9781788296243/72473bdb-ac6f-457f-9f10-63d252f63c9f.xhtml
  28. https://blogs.microsoft.com/blog/2016/02/24/microsoft-to-acquire-xamarin-and-empower-more-developers-to-build-apps-on-any-device/
  29. https://tonyqus.medium.com/miguel-de-icaza-and-open-source-history-of-net-773d1500a112
  30. https://opensource.microsoft.com/blog/2016/02/25/microsoft-to-acquire-xamarin-a-leading-platform-for-cross-platform-app-development/
  31. https://devclass.com/2024/08/28/microsoft-quietly-donates-mono-project-to-winehq-but-why/
  32. https://www.theregister.com/2025/03/11/new_wineflavored_version_of_mono/
  33. https://arstechnica.com/gadgets/2024/08/a-long-weird-foss-circle-ends-as-microsoft-donates-mono-to-wine-project/
  34. https://www.phoronix.com/news/Microsoft-Gives-Mono-To-Wine
  35. https://lwn.net/Articles/987465/
  36. https://news.ycombinator.com/item?id=41371106
  37. https://www.winehq.org/news/2025030801
  38. https://www.mono-project.com/docs/advanced/runtime/
  39. https://manpages.debian.org/testing/mono-runtime-common/mono.1.en.html
  40. https://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen/
  41. https://www.mono-project.com/community/contributing/the-class-library/
  42. https://www.mono-project.com/docs/about-mono/compatibility/
  43. https://stackoverflow.com/questions/22462829/library-compatibility-between-c-sharp-net-vs-c-sharp-mono
  44. https://learn.microsoft.com/en-us/dotnet/standard/class-libraries
  45. https://www.mono-project.com/docs/advanced/aot/
  46. https://www.mono-project.com/docs/advanced/runtime/docs/aot/
  47. https://manpages.debian.org/unstable/mono-runtime-common/mono.1.en.html
  48. https://learn.microsoft.com/en-us/dotnet/framework/
  49. https://www.mono-project.com/news/2018/09/11/csharp-jit/
  50. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/
  51. https://learn.microsoft.com/en-us/dotnet/fundamentals/implementations
  52. https://www.monodevelop.com/
  53. https://www.mono-project.com/docs/about-mono/showcase/software/
  54. https://docs.lextudio.com/blog/the-end-of-monodevelop-80b383dab34b
  55. https://visualstudiomagazine.com/articles/2022/01/26/vs-mac-preview-5.aspx
  56. https://learn.microsoft.com/en-us/visualstudio/releases/2022/what-happened-to-vs-for-mac
  57. https://code.visualstudio.com/docs/languages/csharp
  58. https://www.mono-project.com/docs/getting-started/development-environments/
  59. https://www.mono-project.com/docs/about-mono/supported-platforms/apple/
  60. https://www.mono-project.com/docs/about-mono/supported-platforms/android/
  61. https://dotnet.microsoft.com/en-us/apps/xamarin
  62. https://learn.microsoft.com/en-us/answers/questions/281890/xamarin-android-application-why-is-shared-runtime
  63. https://sam-solutions.com/blog/xamarin-cross-platform-development/
  64. https://raygun.com/blog/life-beyond-xamarin-future-of-mobile-development/
  65. https://github.com/dotnet/runtime/tree/main/src/mono
  66. https://gitlab.winehq.org/wine-mono/mono
  67. https://docs.unity3d.com/6000.2/Documentation/Manual/scripting-backends-mono.html
  68. https://www.mono-project.com/docs/web/moonlight/
  69. https://github.com/mono/moon
  70. https://www.mono-project.com/docs/about-mono/supported-platforms/
  71. https://www.mono-project.com/download/stable/
  72. https://www.tecmint.com/install-mono-net-framework-linux/
  73. https://www.mono-project.com/docs/compiling-mono/linux/
  74. https://www.mono-project.com/docs/faq/technical/
  75. https://www.mono-project.com/docs/getting-started/application-deployment/
  76. https://www.mono-project.com/docs/about-mono/supported-platforms/macos/
  77. https://www.mono-project.com/docs/getting-started/install/mac/
  78. https://github.com/mono/monomac
  79. https://stackoverflow.com/questions/5862972/how-to-create-a-app-mono-bundle-for-mac-os
  80. https://www.xlsoft.com/en/products/xamarin/faq.html
  81. https://www.mono-project.com/docs/advanced/embedding/
  82. https://bec-systems.com/191/c-on-embedded-arm-linux-systems-is-now-practical/
  83. https://github.com/mono/mono/tree/master/samples/embed
  84. https://www.mono-project.com/docs/advanced/pinvoke/
  85. https://www.mono-project.com/news/2020/08/24/native-loader-net5/
  86. https://www.mono-project.com/docs/faq/licensing/
  87. https://stackoverflow.com/questions/52133892/do-i-need-a-special-license-to-distribute-a-mono-executable-cross-compiled-with
  88. https://github.com/mono/mono/blob/main/LICENSE
  89. https://www.theregister.com/2009/07/07/mono_microsoft_promise/
  90. https://www.microsoft.com/en-us/legal/intellectualproperty/tech-licensing/customer-agreements
  91. https://www.fsf.org/news/dont-depend-on-mono
  92. https://www.zdnet.com/article/stallman-warns-of-mono-risk/
  93. https://www.linux-magazine.com/Online/News/Mono-Discussion-Stallman-Warns-Ubuntu-Dismissive
  94. https://lwn.net/Articles/339314/
  95. https://www.osnews.com/story/21753/stallman-warns-of-mono-right/
  96. https://bansheemediaplayer.github.io/
  97. https://bansheemediaplayer.github.io/download/
  98. https://github.com/xamarin/mono-sdks
  99. https://www.mono-project.com/docs/advanced/garbage-collector/sgen/
  100. https://askubuntu.com/questions/236952/is-there-a-performance-difference-between-running-net-applications-via-mono-and
  101. https://tirania.org/blog/archive/2009/Jul-27.html
  102. https://developercommunity.visualstudio.com/content/problem/224073/aspnet-core-20-with-net-framework-461-cant-not-wor.html
  103. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR
  104. https://www.researchgate.net/publication/221134118_Mono_versus_net_A_Comparative_Study_of_Performance_for_Distributed_Processing
  105. https://www.reddit.com/r/dotnet/comments/1mfy7yk/sanity_check_on_net_framework_mono_macos/
  106. https://stackoverflow.com/questions/4930822/garbage-collection-worst-case-performance-on-mono
  107. https://stackoverflow.com/questions/37542784/why-an-unmanaged-thread-in-mono-it-freezes-due-to-the-garbage-collector-while-us
  108. https://tirania.org/blog/archive/2018/Apr-11.html
  109. https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/
  110. https://tirania.org/blog//texts/pdc-2005.html
  111. https://stackoverflow.com/questions/1142065/what-are-the-arguments-against-mono-does-the-microsoft-community-promise-change
  112. http://www.linux-magazine.com/Online/Blogs/Off-the-Beat-Bruce-Byfield-s-Blog/Miguel-de-Icaza-and-his-ostracization-from-FOSS
  113. https://techrights.org/o/2008/02/22/mark-shuttleworth-on-patents/
  114. https://www.redmonk.com/public/mono_cc_licensed.pdf
  115. https://sdtimes.com/microsoft/from-the-editors-microsoft-should-rescue-mono/
  116. https://www.mono-project.com/docs/about-mono/releases/
  117. https://devblogs.microsoft.com/dotnet/introducing-net-5/
  118. https://www.mono-project.com/docs/about-mono/dotnet-integration/
  119. https://learn.microsoft.com/en-us/dotnet/maui/what-is-maui?view=net-maui-9.0
  120. https://learn.microsoft.com/en-us/dotnet/maui/macios/interpreter?view=net-maui-9.0
  121. https://www.cnet.com/tech/services-and-software/novell-ships-cross-platform-mono-tool/
  122. https://news.itsfoss.com/microsoft-donates-mono-project/
Add your contribution
Related Hubs
User Avatar
No comments yet.