.NET Core is the newest and the hottest programming platform in Microsoft stack. And this is the platform that Microsoft says that developers should use, unless they have a compelling reason not to.
The biggest selling point of .NET Core over its predecessor, .NET Framework, is that, .NET Core can run on Windows, Linux and Mac, while .NET Framework could only run on Windows. However, the ability to run .NET code on multiple operating systems isn’t new. We had it for years since the release of mono.
And, unlike .NET Core, 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 Core can while .NET Core can only do some of the things that mono can, why is .NET Core is being so heavily promoted, while mono isn’t?
Well, in reality, each of these programming platforms has its place. There are scenarios where .NET Core is a way better choice than mono, despite its limitations. And those scenarios are very common these days.
Let’s examine the differences between .NET Core and mono, so you can decide for yourself which platform to use in any given situation.
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 .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 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 afterwards, he has 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 has 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 in mono shortly afterwards. 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 afterwards.
However, this did not stop mono development. In the same year, Miguel de Icaza has founded his own company and called it Xamarin. Prior to this, he has 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 in Microsoft products, such as Visual Studio. This is also why Microsoft’s own publications, such as MSDN Magazine, regularly write about Xamarin.
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 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.
Brief history of .NET Core
When .NET Framework was on its version 4 for a while with just a couple of incremental minor version releases coming out at regular intervals, the guys 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 newly introduced JSON format back to classic XML, but it was enormously improved compared to what it used to be. All of unnecessary verbosity has been removed.
Since then, .NET Core went a long way. Currently it still lacks many of the feature that are available with many other programming platforms. For example, you have to use a third party library to get your app to play audio. But with .NET Core 3, you can achieve pretty much anything you could do with .NET Framework.
Although GUI-enabled desktop apps that you can build with .NET Core are still restricted to Windows, pretty much everything else can be ran on Linux and Mac too. So, you no longer have to host your web application or a set of microservices on an expensive Windows machine. Open-source Linux distro will do just fine.
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 to use mono
Mobile app development
Using .NET for mobile app development was always focus for 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.
.NET Core, on the other hand, doesn’t come with anything that will allow you to write mobile apps. It’s never been intended for this purpose.
Game development
Unity gaming engine uses mono inside of it, so mono is the official way of getting your .NET code into games.
.NET Core, 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 Core is of no use.
Compiled code inside browser
WebAssembly allows you to run a compiled code inside 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 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 doesn’t have such capability natively. Although it was initially used for Blazor project, it was abandoned in favour of mono.
Multi-platform desktop applications
Desktop applications on operating systems other than Windows was the reason why mono was developed in the first place. Since then, countless frameworks and libraries were built around it to accommodate GUI-based application development on Windows, Linux, Mac OS and even Solaris.
Having said that, there are situations where .NET Core is a better choice for desktop application development. More on this later.
The main scenarios where mono would be a better choice for desktop application development than .NET Core is if you have limited knowledge of JavaScript or if you want your application to run on Solaris, which .NET Core doesn’t support.
Where to use .NET Core
Command-line applications
At the most basic level, .NET Core is a console applications that can be interested with 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 Core should be your choice.
Of course, you can do an OS-independent command-line application in mono as well. But why bother, if .NET Core 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 development of web applications on top of .NET Core, 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 easily configurable middleware pipilene.
Also, with revamped version of SignalR library and server-side Blazor, you can now maintain a 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 Core allows you to build such applications just as easily as you can build some basic console apps.
Desktop applications
This point would be controversial, as .NET Core doesn’t have in-built way of developing cross-platform GUI-enabled desktop applications.
However, if you only intend to run your desktop app on Windows, then .NET Core 3 provides support for this. And, just like with everything else in .NET Core, 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 Core may 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 of 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 Core? 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, Electron.NET application is not radically different from a standard ASP.NET application. The only differences are that both back-end and front-end parts are hosted in the same process.
The choice between the two won’t matter soon
In any case, you won’t have to scratch your head about which of these platforms to choose for much longer. In 2020, Microsoft is releasing .NET 5, which will incorporate all the functionality from both of these platforms and will even include some features from .NET Framework that are currently missing from both of them.
So, from then onward, you will have just a single platform. All you’ll have to do is choose its version number and the application type. Nothing else will distract you from crafting your next awesome app.