Historically, .NET Framework was a Windows-only software development framework. In fact, many developers who don’t regularly work with it still believe that .NET and its languages, such as C#, are only available on Windows.
It all changed in 2016 when .NET Core was released. The biggest selling point of .NET Core over its predecessor, .NET Framework, is that .NET Core can run on Windows, Linux, and Mac. Since the release of .NET 5 in 2020, it is no longer called .NET Core. It’s just called .NET. The Windows-only .NET Framework is now considered to be a legacy framework.
However, the ability to run .NET code on multiple operating systems isn’t new. We had it for years since the release of mono. Unlike .NET, which natively only allows you to build console apps and web applications, mono allows you to build many application types available in .NET Framework, including GUI-enabled desktop apps. So, if mono can do everything that .NET can while .NET can only do some of the things that mono can, why is .NET being so heavily promoted, while mono isn’t?
Well, in reality, each of these programming platforms has its place. Mono is still heavily used in the industry, but there are some reasons why you may not be hearing much about it anymore. Let’s find out why.
A brief history of mono
Mono is way older than .NET Core. The development of it started pretty much when the initial .NET Framework was announced in the year 2000. Although many parts of the .NET Framework were to be proprietary and patented by Microsoft, the company has published its underlying Common Language Infrastructure (CLI) as an open ECMA-approved standard, enabling developers outside of Microsoft to build independent implementations of .NET.
This did not go unnoticed by Miguel de Icaza, who then worked for a company called Ximian. As the upcoming .NET Framework was specifically designed for Windows, he decided to use the CLI to create his own Linux version of it. Not very long afterward, he realized that this would be a vast task that cannot be done by a small team of developers within a reasonable amount of time. So, in 2001, he open-sourced the project.
Since then, the evolution of mono followed the pace of .NET Framework development. For example, whenever a new version of C# language would be released, it would be integrated into mono shortly afterward. The same would apply to the changes in the system class libraries and other core components of the system.
In 2003 a company called Novell acquired Ximian and the original mono team continued overseeing the development of mono while being employed by this new company. This continued until a company called Attachmate acquired Novell in 2011 and laid off the mono team shortly afterward.
However, this did not stop mono development. In the same year, Miguel de Icaza founded his own company and called it Xamarin. Prior to this, he developed frameworks based on mono that would allow users to write Android and iOS apps in .NET code. And luckily, Attachmate has allowed him to retain ownership of these. Since then, making tools for mobile app development became the main focus for Xamarin and this is what the company is known for.
In 2016, Xamarin was purchased by Microsoft, so all of its tools are now fully integrated into Microsoft products, such as Visual Studio. Prior to this, many Microsoft stack developers weren’t even aware that such a thing as mono existed, despite many of its uniquely useful features. And the key reason for this was that mono wasn’t related to Microsoft in any way, so the company didn’t have any reason to mention it anywhere in its literature.
So, after all these years of its evolution, mono is capable of running many of the original .NET Framework application types on operating systems other than Windows. This includes GUI-enabled desktop applications, which can now be made compatible with virtually any modern desktop operating system, including Solaris.
As well as this, together with a wide range of Xamarin tools, mono enables cross-platform mobile app development where a shared codebase can be compiled into a native format for either Android or iOS.
Unity video game engine that can be used on a whole range of gaming platforms has also adopted mono. Finally, another worthy application of mono is client-side Blazor, which allows the execution of compiled .NET code directly inside browsers on top of WebAssembly.
A brief history of .NET Core
When .NET Framework was on version 4 for a while with just a couple of incremental minor version releases coming out at regular intervals, the developers at Microsoft decided to finally develop version 5. And, unlike its predecessor, version 5 was envisioned to be platform-independent and not just tied to Windows.
But they didn’t just want to make .NET Framework OS-independent. Mono has achieved this already. They wanted to completely re-architecture .NET Framework by getting rid of various code smells and anti-patterns and by applying various other improvements.
However, after realizing how enormous this task would be, the company decided to release a totally new programming platform, which became known as .NET Core. Presumably, the name signified that the platform itself only had the minimal core components required to run your apps on various operating systems, while the rest of the functionality was expected to be introduced by the community of developers as third-party libraries.
So, in 2016, the first version of .NET Core has been released. That particular version was way too limited to be useful. All you could do with it was write some basic console applications and some web applications with very limited functionality. Until SignalR was officially added to the platform in the following year, there wasn’t even an easy way to establish a persistent real-time connection between the client and the server.
But nevertheless, the platform still had some advantages over .NET Framework. It was now way easier to put together an MVC or Web API web application. And the project files were actually readable compared to the old verbose .NET Framework style.
The project file format has changed between versions 1 and 2 from the newly introduced JSON format back to classic XML, but it was enormously improved compared to what it used to be. All of the unnecessary verbosity has been removed.
Since then, .NET Core went a long way. Since .NET Core evolved into .NET, it’s now a truly cross-platform software development framework. You can now build any application type with it, ranging from web applications to native applications for mobile and desktop devices. And, on top of that, your apps are now significantly easier to put together.
So, as you now have a basic idea of where each of these programming platforms came from, let’s have a look at the use cases for each of them.
Where is mono used?
The thing about mono is that you will struggle to find a scenario that will allow you to use it directly. And this is precisely why you hardly hear about mono as a software development framework. It is now primarily a core component of other software development frameworks but not a framework of its own. Nevertheless, here are some scenarios where mono is used:
Mobile app development
Using .NET for mobile app development was always the focus of Xamarin since its inception, so without a doubt, this is where you will be using mono. That is, of course, unless you opt for writing the apps in their native languages, which would be either Kotlin or Java for Android and either Swift or Objective-C for iOS.
If you do opt to go native, however, you will be only able to write your code for one OS at a time. With mono-based Xamarin tools, on the other hand, you can have a single code base, which you can compile for both Android and iOS.
Xamarin has since evolved into .NET MAUI which can build apps for Windows and Mac and not just mobile applications. But it still uses mono underneath.
Game development
Unity gaming engine uses mono inside of it, so mono is the official way of getting your .NET code into games. .NET, on the other hand, was never intended for gaming. So, unless you want to build a text-based adventure or some relatively basic browser-based game, .NET is of no use in this situation.
Compiled code inside a browser
WebAssembly allows you to run a compiled code inside the browser. Unlike other technologies, such as Silverlight, Java, and Flash that required vendor-specific browser plugins, WebAssembly is a web standard. And as such, it’s supported by all major browsers.
Mono has an in-built capability to be compiled into WebAssembly-compatible packages. And, as such, it was a natural choice for the base framework behind client-side Blazor. .NET Core didn’t initially have this capacity. However, this is not the case anymore and Blazor is now using .NET.
Where is .NET used?
Command-line applications
At the most basic level, .NET is a console application that can be initiated via a command-line interface, such as Windows Command Prompt or Linux Terminal. So, if you need to build an OS-independent command-line application, .NET should be your choice.
Of course, you can do an OS-independent command-line application in mono as well. But why bother, if .NET gives you a much better project file structure and system libraries that are way easier to work with?
Web applications
ASP.NET Core, the set of libraries that enable the development of web applications on top of .NET, is way easier to work with than mono equivalent, while it can do everything mono can and more. Through trial and error, Microsoft developers made it possible to set up basic web applications in minutes with an easily configurable middleware pipeline.
Also, with a revamped version of the SignalR library and server-side Blazor, you can now maintain persistent real-time two-way communication between your client and server components with very little code required.
Background services
Any application that runs continuously in the background and doesn’t have GUI can be classed as a service. And .NET allows you to build such applications just as easily as you can build some basic console apps.
Desktop applications
There are many ways of developing desktop applications on .NET. If you only intend to run your desktop app on Windows, then .NET provides support for this. And, just like with everything else in .NET, the experience of creating this application type has been vastly improved compared to how it was done in .NET Framework.
On the other hand, if you want to make your desktop application for multiple operating systems, .NET can still be the best choice. There is a great cross-platform JavaScript framework for building desktop applications called Electron.js and with Electron.NET NuGet package, you can integrate it with your .NET Core app.
The unique selling point of this approach is that your entire GUI is done in HTML, CSS, and JavaScript, just like a web page. The only difference is that all of it is hosted on your machine inside the desktop application itself. And, instead of being displayed in the browser, it’s displayed in its own window.
Because front-end technologies have massively evolved over the years, the possibilities of what you can do inside your GUI are limitless. You can use absolutely any JavaScript library or framework available. Therefore, if you have seen how easy it can be to create web pages with an impressive layout, you can do it just as easily inside your desktop application.
You may ask though, why even bother integrating it with .NET? Why not just use Electron.js directly? There are several reasons for that.
First of all, your back-end code will be compiled. So, if you don’t want to have your code accessible to the users, you won’t have to. Likewise, in this scenario, your .NET code can do any background logic it would normally do on the server of a web application.
Essentially, an Electron.NET application is not radically different from a standard ASP.NET application. The only difference is that both back-end and front-end parts are hosted in the same process.
Also, you may forget about all of these choices and use the abovementioned .NET MAUI. Because this platform is an evolution of Xamarin, it still uses mono. But it also uses many standard .NET components. Developing a .NET MAUI application looks and feels the same as developing any other .NET application, so this is an example of a system where .NET and mono nicely complement each other.
Wrapping up
So, there is a good reason why you probably aren’t hearing as much about mono. There is almost no scenario where you would use it directly. And, unless you develop games in Unity, you would probably end up using .NET and mono together.
It really isn’t an either-or choice between .NET and mono. Both frameworks do their job and do it well. And they complement each other quite well. While .NET is moving into becoming a universal software development framework suitable for any application development scenario, chances are that some of these scenarios will use components from mono underneath.
P.S. If you want me to help you improve your software development skills, you can check out my courses and my books. You can also book me for one-on-one mentorship.