Mono vs..NET Core

Problem

What’s the difference between Mono and.NET Core?

“Code built for it is also portable across application stacks, such as Mono,” according to a statement on the official site.

My goal is to construct a website that can be run/hosted on Linux using C#, LINQ, EF7, and Visual Studio.

Someone said he wanted it “in Mono,” but I have no idea what that means. I’m very sure I’m going to use.NET Core 1.0 with the technologies I mentioned earlier. He also stated that he desired to use “rapid CGI.” I have no idea what that implies.

Can you explain all of these words to me and tell me if my expectations are reasonable?

Asked by Captainlonate

Solution #1

Necromancing. Providing an actual answer.

.NET Core is currently the official successor to.NET Framework. It began with a rewrite of the ASP.NET MVC framework and console applications, which included server applications, for the most part. (Because it’s Turing-complete and allows interop with C dlls, you could, if you really wanted to, use it to develop your own desktop programs, for example through 3rd-party libraries like Avalonia, which were a little rudimentary when I initially wrote this, limiting you to web or server stuff.) Many APIs have been introduced to.NET Core throughout time, to the point that, after version 3.1, it will be known as.NET 5.0 without the “Core,” and that will be the final version.

Apart from multi-platform support, the main goal of.NET Core is to enhance performance and enable “native compilation”/self-contained-deployment (so you don’t require the.NET framework or VM on the destination machine). On the one hand, this means Linux support for Docker.io, and on the other, self-contained deployment is useful in “cloud computing,” because you can use whatever version of the dotnet-CORE framework you want, and you don’t have to worry about which version(s) of the.NET framework the sysadmin has installed.

While the.NET Core runtime is compatible with a variety of operating systems and CPUs, the SDK is not. While the SDK supports a variety of operating systems, ARM compatibility is/was still in the works. Microsoft backs the.NET Core framework. WinForms, WPF, and other similar components were not included with Dotnet-Core.

The “Mono Project” predates.NET Core by several years. Mono is a Spanish word that meaning “monkey,” and it has nothing to do with mononucleosis (hint: a list of employees may be found at http://primates.ximian.com/). Mono was created in 2005 by Miguel de Icaza (the creator of GNOME and a few other projects) as a.NET Framework for Linux (Ximian/SuSe/Novell) implementation. Web-Forms, Winforms, MVC, Olive, and MonoDevelop are all part of Mono (also knows as Xamarin Studio or Visual Studio Mac). As opposed to SUN/Oracle JDK, this is basically the equal of (OpenJDK) JVM and (OpenJDK) JDK/JRE. It allows you to run ASP.NET-WebForms, WinForms, and ASP.NET-MVC apps on Linux. Xamarin (the new corporate name for what used to be known as Mono) supports Mono.

As far as .NET Core is concerned, when they say cross-platform, don’t expect that cross-platform means that you could actually just apt-get install .NET Core on ARM-Linux, like you can with ElasticSearch. You’ll have to compile the framework from the ground up. That is, if you have that space (e.g. on a Chromebook, which has a 16 to 32 GB total HD). It also used to have issues of incompatibility with OpenSSL 1.1 and libcurl. Those have been rectified in the latest version of .NET Core Version 2.2. So much for cross-platform.

As long as that code doesn’t rely on WinAPI-calls, Windows-dll-pinvokes, COM-Components, a case-insensitive file system, the default-system-encoding (codepage) and doesn’t have directory separator issues, that’s correct. .NET Core code, on the other hand, runs on.NET Core rather than Mono. As a result, combining the two will be tough. And since Mono is quite unstable and slow (for web applications), I wouldn’t recommend it anyway. Try image-processing on .NET core, e.g. WebP or moving GIF or multipage-tiff or writing text on an image, you’ll be nastily surprised.

Code that was not written for.NET (non-Core) will not run on.NET Core. That is, if you wish to make PDF documents with a non-GPL C# package like PDFSharp (which is fairly common), you’re out of luck (for the time being) (not anymore). Never mind the ReportViewer control, which uses Windows-pInvokes (to encrypt, create mcdf documents via COM, and get font, character, kerning, font embedding information, measure strings and do line-breaking, and actually draw acceptable tiffs), and doesn’t even run on Mono on Linux (though I’m working on it).

Also, because Mono lacks the.NET Core runtime libraries, code created in.NET Core is not portable to Mono (so far).

I wouldn’t suggest EF in any version I’ve used so far because it was so freaking slow (even on trivial tasks like one table with one left-join), and I wouldn’t recommend it on Windows either. If you have a database with unique constraints or varbinary/filestream/hierarchyid columns, I would strongly advise against using EF. (Neither for schema-update.) Also, not in a circumstance where database performance is crucial (say, tens to hundreds of concurrent users). Running a website/web-application on Linux also means you’ll have to troubleshoot it sooner or later. On Linux, there is no debugging support for.NET Core. (Not any more; however, JetBrains Rider is required.) Debugging.NET Core projects is not supported by MonoDevelop (yet). You’re on your own if you encounter issues. You’ll need to do a lot of logging. Be

Either he doesn’t want to utilize.NET Core or he just wants to use C# on Linux/Mac. My guess is that he simply wants to use C# on Linux for a Web application. If you really must do it in C#, then.NET Core is the way to go. Don’t use “Mono proper”; it may appear to work at first glance, but believe me when I say that you will be sorry since Mono’s ASP.NET MVC isn’t stable while your server runs long-term (more than 1 day) – you have been warned. When measuring Mono performance on the techempower benchmarks, keep in mind the “did not complete” references.

It suggests he wants to utilize nginx (Engine-X), or potentially Apache, as a high-performance, full-featured WebServer. Then he can use mono/dotnetCore with virtual name based hosting (many domain names on a single IP address) and/or load balancing. He can also operate additional websites using other technologies without needing to change the web server’s port number. It means that your website is hosted on a fastcgi server, and that nginx routes all web requests for a certain domain to that server using the fastcgi protocol. It also means that your website operates in a fastcgi-pipeline, which means you must be cautious about what you do, such as not using HTTP 1.1 when sending files. Otherwise, files will be distorted when they arrive at their final destination. Also see here and here.

To summarize,.NET Core is neither truly portable or cross-platform at this time (2016-09-28). (in particular the debug-tools). It’s also not straightforward to compile natively, especially on ARM. It also doesn’t appear to me that its development is “completed” yet. Take, for instance, System. Data.DataTable/DataAdaper. The most recent update is missing… (This is no longer the case with.NET Core 2.0) The System.Data.Common.IDB* interfaces are used in conjunction with them. (Not with.NET Core 1.1) If there is one class that is frequently used, it is DataTable/DataAdapter… Also, at least on my machine, the Linux-installer (.deb) fails, and I’m sure I’m not the only one who has this issue. If you can build it on ARM (which I did – don’t follow Scott Hanselman’s blog post if you can), debug it with Visual Studio Code.

It, if you want to run.NET Core “RTM” behind nginx, you can only do so by proxying requests to kestrell (that half-finished nodeJS-derived web-server) – AFAIK,.NET Core “RTM” doesn’t support fastcgi. It’s also doubtful that anyone tested the framework to ensure that fastcgi works as intended because there is no.net core fastcgi library and no samples.

I’m also concerned about the performance. Aspnetcore-linux ranks 25% below the best performance in the (preliminary) techempower-benchmark (round 13), while related frameworks like Go (golang) rank at 96.9% of peak performance (and that is when returning plaintext without file-system access only). .NET Core does a little better on JSON-serialization, but it does not look compelling either (go reaches 98.5% of peak, .NET core 65%). That said, it can’t possibly be worse than “mono proper”.

Also, because it’s still new, not all of the big libraries have been ported (yet), and I doubt that some of them will be ported in the future. Support for imaging is similarly dubious at best. Instead, use BouncyCastle for any encryption needs.

I hope I was able to clarify some of these terms for you. In terms of your expectations, developing a Linux program without knowing anything about Linux is a terrible idea in the first place, and it’s almost certain to fail horribly in some way. However, because Linux has no licensing fees, it is an excellent concept in theory, BUT ONLY IF YOU KNOW WHAT YOU’RE DOING. Another terrible idea is to create an application for a platform where you won’t be able to debug it. Another terrible idea is to develop for fastcgi without first understanding the repercussions.

If your project is more than a personal webpage, doing all of this on a “experimental” platform without any knowledge of the platform’s characteristics and without debugging support is suicide. On the other side, I imagine doing it for learning purposes with your personal homepage would be a great experience – you’ll understand what the framework and non-framework challenges are. To get around case-sensitivity difficulties, you can loop-mount a case-insensitive fat32, hfs, or JFS for your application (programmatically) (loop-mount not recommended in production).

To sum it up At this time (2016-09-28), I would avoid using.NET Core (for production usage). You might be able to revisit it in one to two years, but not sooner. If you’re working on a new web project, start with.NET Core rather than mono. Use Golang instead of.NET, Java, or Windows if you want a framework that works on Linux (x86/AMD64/ARMhf), Windows, and Mac and has no dependencies, i.e. only static linking and no dependency on.NET, Java, or Windows. It’s more mature, has proven performance (Baidu uses it with 1 million concurrent users), and has a far smaller memory footprint. Golang is also available in the repositories; the.deb package installs without issue, the source code compiles without modification, and golang (in the meanwhile) is available.

Mono should be avoided at all costs. Mono has gone a long way, but it doesn’t change the fact that it still has performance, scalability, and stability difficulties in industrial applications. Mono-development is also essentially gone; they now primarily develop components that are relevant to Android and iOS because that is where Xamarin gets their money. Expect Web-Development to be a second-class Xamarin/mono citizen;.NET Core may be worthwhile if you’re starting a new project, but transferring existing major web-forms applications is basically out of the question due to the significant modifications necessary. If you have an MVC project, the quantity of changes you make may be tolerable if your original application design was reasonable, which is rarely the case.

Native compilation has been removed from the.NET Core preview because it is not yet ready… December 2016 Update: Native compilation has been removed from the.NET Core preview because it is not yet ready… On the one hand, it appears that they have made significant progress on the raw text-file benchmark, but on the other hand, it has become somewhat buggy. In addition, it got worse in the JSON benchmarks. It’s also intriguing that entity framework will be faster for updates than Dapper, despite the fact that they’re both extremely slow. This is very unlikely to be true. Looks like there still are more than just a few bugs to hunt. Also, there seems to be relief coming on the Linux IDE front. JetBrains released “Project Rider”, an early access preview of a C#/.NET Core IDE for Linux (and Mac and Windows), that can handle Visual Studio Project files. Finally a C

Conclusion: As we head into 2017,.NET Core remains pre-release quality software. Port your libraries, but don’t use it in production until the framework’s quality improves. Keep an eye on Project Rider as well.

Updated in 2017 For the time being, I’ve switched my (brother’s) homepage to.NET Core. So far, the Linux runtime appears to be stable enough (at least for small projects) – it easily passed a load test, whereas mono failed miserably. Also,.NET-Core-native and.NET-Core-self-contained-deployment appear to have been muddled up. Self-contained deployment works, although it’s a little underdocumented, despite how simple it is (the build/publish tools are still a little shaky, so if you get “Positive number required. – Build FAILED.” – just run the same command again, and it’ll work).

You can run

dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64

dotnet publish -r win-x64 -c Release /p:PublishSingleFile=true
dotnet publish -r linux-x64 -c Release /p:PublishSingleFile=true

You also get a self-contained.exe file (in the publish directory) that you may execute on a Windows 8.1 PC that doesn’t have the.NET framework installed. Nice. It’s at this point when dotNET-Core really starts to shine. (mind the gaps, SkiaSharp doesn’t work on Windows 8.1 / Windows Server 2012 R2, [yet] – the ecosystem has to catch up first – but interestingly, the Skia-dll-load-fail doesn’t crash the entire server/application – so everything else works)

(Note: On Windows 8.1, SkiaSharp is missing the VC runtime files msvcp140.dll and vcruntime140.dll. Skia will work on Windows 8.1 if you copy them into the publish-directory.)

Updated on August 2017 .NET Core 2.0 is now available. Be cautious, as it comes with (major) authentication changes… On the plus side, it reinstated the DataTable/DataAdaper/DataSet classes, among others. Because Mobius hasn’t been ported yet,.NET Core still lacks support for Apache SparkSQL. That’s bad, because that means no SparkSQL support for my IoT Cassandra Cluster, so no joins… Experimental ARM support (runtime only, not SDK – too bad for devwork on my Chromebook – looking forward to 2.1 or 3.0). PdfSharp is now experimentally ported to .NET Core. JetBrains Rider left EAP. You can now use it to develop & debug .NET Core on Linux – though so far only .NET Core 1.1 until the update for .NET Core 2.0 support goes live.

It was only fixed in v2.1; there was no bugfix release for 2.0). However, I will not be installing preview releases on my computer. So here we are, waiting. Compile times are stated to be drastically reduced in v2.1. That would be excellent.

Also, keep in mind that.NET Core is only available in 64-bit mode on Linux! On Linux, there is no x86-32 version of.NET Core, and there will be none in the future. And the ARM port is exclusively for ARM-32. No ARM-64, yet. And on ARM, you (at present) only have the runtime, not the dotnet-SDK.

Also, because.NET Core for Linux utilizes OpenSSL 1.0, it does not run on Arch Linux, and by extension, not on Manjaro (by far the most popular Linux distro at this moment), because Arch Linux requires OpenSSL 1.1. You’re out of luck if you’re using Arch Linux (with Gentoo, too).

Edit:

On the plus side, results have improved significantly:

.NET Core 3:.NET-Core v 3.0 is stated to have WinForms and WPF support. While WinForms and WPF will be.NET Core, they will only run on Windows because WinForms and WPF will use the Windows-API.

Note:.NET Core 3.0 is now available (Release to Manufacturing), and it includes WinForms and WPF compatibility, but only for C# (on Windows). WinForms-Core-Designer does not exist. Sometime in the future, the designer will be included in a Visual Studio upgrade. Support for WinForms in VB.NET is not currently available, however it is planned for.NET 5.0 sometime in 2020.

PS:

echo "DOTNET_CLI_TELEMETRY_OPTOUT=1" >> /etc/environment
export DOTNET_CLI_TELEMETRY_OPTOUT=1 

You’ve probably never seen this if you’ve used it on windows:

I just wanted to remark that I think monodevelop (also known as Xamarin Studio, the Mono IDE, or Visual Studio Mac on Mac) has matured wonderfully and is largely useful in the meanwhile. However, if you develop.NET-Core on Linux or Mac, JetBrains Rider (2018 EAP at this time) is undoubtedly a much prettier and more dependable (plus the integrated decompiler is a lifesaver). MonoDevelop does not support Debug-StepThrough on Linux in .NET Core, though, since MS does not license their debugging API dll (except for VisualStudio Mac … ). However, you can use the Samsung debugger for .NET Core through the .NET Core debugger extension for Samsung Debugger for MonoDevelop

Disclaimer: Because I don’t own a Mac, I can’t say whether or not what I’ve written here applies to Macs running FreeBSD-Unix. I’m referring to JetBrains Rider, mono, MonoDevelop/VisualStudioMac/XamarinStudio, and.NET-Core for Linux (Debian/Ubuntu/Mint). Furthermore, Apple is considering switching from Intel-based processors to self-manufactured ARM(ARM-64?)-based processors, thus much of what pertains to Mac today may not apply to Mac in the future (2020+).

Also, when I say “mono is quite unstable and slow,” I’m referring to WinForms and WebForms applications, specifically executing web-applications via fastcgi or with XSP (on the 4.x version of mono), as well as XML-serialization-handling quirks, and the quite-slow relates to WinForms, and regular expressions in particular (ASP.NET-MVC uses regular expressions for routing as well).

When I talk about my experiences with mono 2.x, 3.x, and 4.x, I’m not implying that these issues haven’t been handled by now, or by the time you read this, or that even if they have, there won’t be a regression later that reintroduces any of these bugs/features. That doesn’t mean that embedding the mono-runtime will get the same effects as using the (dev) system’s mono runtime. It also doesn’t imply that embedding the mono-runtime (in any location) is always cheap.

All of this isn’t to say that mono isn’t suitable for iOS or Android, or that it has the same issues. Because I don’t use mono on Android or iOS, I can’t comment on stability, usability, prices, or performance on these platforms. Naturally, if you use.NET on Android, you’ll have to factor in additional costs, such as weighing xamarin-costs against the cost and effort of converting existing code to Java. Mono on Android and iOS is expected to be fairly nice. It should be taken with a grain of salt. For starters, don’t expect the default-system-encoding on Android/iOS and Windows to be the same, nor the Android filesystem to be case-insensitive, nor any Windows fonts to be case-insensitive.

Answered by Stefan Steiger

Solution #2

There are two sorts of CLRs in the.NET world: “full” CLRs and Core CLRs, which are substantially distinct.

There are two “full” CLR implementations, the Microsoft native .NET CLR (for Windows) and the Mono CLR (which itself has implementations for Windows, linux and unix (Mac OS X and FreeBSD)). A complete CLR is simply that – everything you’ll ever need. As such, “full” CLRs tend to be large in size.

Core CLRs, on the other hand, are significantly reduced in size. Because they are merely a core implementation, they are unlikely to contain everything you require, hence Core CLRs allow you to use NuGet to add feature sets to the CLR that your specific software product relies on. Core CLR implementations are available for Windows, Linux (various), and Unix (Mac OS X and FreeBSD). The.NET framework libraries for Core CLR have been refactored or are being refactored by Microsoft to make them more portable for the core context. Given the ubiquity of mono on *nix OSs, it would be surprising if the Core CLRs for *nix did not include some mono code, but only the Mono community and Microsoft could tell us that.

Also, I agree with Nico that Core CLRs are new — I believe they are now in RC2. I wouldn’t trust it with production code just yet.

To address your question, you could use Core CLR or Mono to offer your site on Linux, which are two alternative approaches. If you want to be safe right now, go with mono on Linux, then port to Core later if you want to.

Answered by muszeo

Solution #3

You’ve picked not just a practical approach, but also possibly one of the best ecosystems supported by Microsoft (including X-platforms). Still, keep the following points in mind:

I hope it becomes useful.

Answered by Otabek Kholikov

Solution #4

. Mono in the sense of the mono framework is not required by Net Core. Net Core is a framework that runs on a variety of operating systems, including Linux. Please see https://dotnet.github.io/ for more information.

The mono framework, on the other hand, can be used by the.Net core. See https://docs.asp.net/en/1.0.0-rc1/getting-started/choosing-the-right-dotnet.html for further information. (Note that only rc1 documentation is accessible; rc2 is not yet available), but mono is not a Microsoft-supported framework, thus it is recommended that you choose one that is.

Entity Framework 7 has been renamed Entity Framework Core, and it now runs on a variety of platforms, including Linux. https://github.com/aspnet/EntityFramework/aspnet/EntityFramework/aspnet/EntityFramework/as (review the road map)

I’m currently using both of these frameworks, however you should be aware that it’s still in the release candidate stage (RC2 is the current version), and there have been significant changes between beta and release candidates that leave you scratching your head.

Here is a tutorial on how to install MVC .Net Core into Linux. https://docs.asp.net/en/1.0.0-rc1/getting-started/installing-on-linux.html

Finally, you may host your application on Linux using a variety of Web Servers (which is where I assume the quick cgi mention comes from). Here’s a starting point for installation to a Linux system. https://docs.asp.net/en/1.0.0-rc1/publishing/linuxproduction.html

I realize this post is primarily documentation links, but those are your greatest sources of information at this moment. Net core is still relatively new in the .Net community and until its fully released I would be hesitant to use it in a product environment given the breaking changes between released version.

Answered by Nico

Solution #5

This is no longer the case. Mono vs. NET Core It’s all in one place.

As of November 2020,.NET 5 has been published, which integrates the.NET Framework and.NET Core.

Under.NET 6, which will be launched in November 2021,.NET and Mono will be merged.

Check below articles:

Answered by Manish Jain

Post is based on https://stackoverflow.com/questions/37738106/net-core-vs-mono