Docs: A similarity is not a difference

[ShalokShalom]

You write:

The major differences between .NET Core and Mono:
...
Open Source -- Mono and .NET Core both use the MIT license and are .NET Foundation projects.

Plus:

APIs -- Mono supports a large subset of the .NET Framework APIs, using the same assembly names and factoring.
Platforms -- Mono supports many platforms and CPUs.

This is also true for .Net Core

And the real technical differences between .Net Core and both, Mono/.Net are also not mentioned at all.

[svick]

Link to the article in question: https://docs.microsoft.com/en-us/dotnet/core/#comparison-with-mono

[ShalokShalom]

Oh, sorry and thank you ^-^

[ninjarobot]

Frameworks

.NET Core applications can readily be server and console applications, but they are only starting to have desktop GUI support or graphics and drawing support. Lots of third party devs are building frameworks like this one, but there's just not a lot of support in the runtime or BCL yet.

.NET Core supports .NET Standard and usually can run (but not build) legacy .NET Code, so long as the code only uses API's supported by the .NET Core runtime. If everything being used targets .NET Standard, you have assurance at build time that it will all run on the platforms that .NET Core supports.

Mono supports .NET 4.5 and later, so can run full framework applications, even including desktop applications since there are frameworks like GTK with .NET bindings. That said, the full .NET framework wasn't designed to be cross platform, and it has API's in it that can't be supported on all platforms. For instance, only root users can adjust the thread priority, so the API does nothing on some platforms. The mono framework tries to do the right thing whenever it can't, but when things don't match, you might get a NotSupportedException or something just unexpected.

API holes aside, mono is able to host many, many more API's than .NET Core since it's a broader runtime, so it's able to take advantage of a larger swath of the ecosystem.

Mono also has full reflection API's, so language features that rely on them, such as F# type providers and XML serializer assemblies have been available all along, whereas .NET Core is slowly getting there.

Building

.NET Core has a fine toolchain for building .NET applications so long as all the source adheres to .NET Standard or there are nuget packages available for everything.

Mono is able to build both full framework application and supports the .NET Core project format, so it's a great SDK for multi-targeting - building for both .NET Core and full framework. There are also several tools that don't yet have .NET Core counterparts:

• mkbundle - creates a self contained executable file containing the native runtime and application's managed dependencies along with a little bit of bootstrapping code to load it all up.
• xsd - generates XML schema definitions (XSD) files from class libraries and can also generate class libraries from .xsd files.
• wsdl - generates web service proxies for SOAP services (yeah, people still have those).
• makecert - can create TLS certs for applications

Platforms

.NET Core is supported on a handful of platforms. Some reasons are technical (like needs a newer glibc), but undoubtedly others come down to being able to have a vendor to support the whole stack, including native platform dependencies.

Mono is supported on far more platforms, albeit there are a number of things that won't work on various platforms. For example, newer mono can use BoringSSL for a nice TLS stack, but only if you build on a system that BoringSSL itself can build on - so no RHEL 6 or CentOS 6, for example. Some examples:

• Alpine
• Arch
• macOS (versions as old as 10.7)
• FreeBSD
• OS/390
• iOS and Android (through embedding the runtime)
• Gaming systems like PS/4 and gaming frameworks like Unity
• Web assembly

It's worth mentioning that all this platform support comes from the community, and so it's inconsistent which releases are available where. For Alpine, the latest right now is 5.2, for FreeBSD, it's 5.4. That's actually a really, really great place to pitch in.

Community vs. Commercial Support

.NET Core is commercially supported, meaning that if there is an issue, there is someone you can pay to fix it. This goes all the way through to the native dependencies, which OS vendors for the supported platforms can support.

Mono is community supported, meaning you're able to work with the community to resolve issues, but there is no official channel for you to get support. If you ship a commercial product, you are likely the one on the hook to support the whole platform unless you can find a third party that does it.

Licensing

.NET Core is MIT licensed, except on Windows there are some libraries and tooling that remain MS-PL licensed, presumably because they have dependencies that necessitate it on Windows. You'll find lots of things link here for the EULA. This license difference seems to only apply to the binaries, not the source, but IANAL.

Mono is MIT licensed by and large. There are a few things that are BSD, GPL and other licenses, all called out on their licensing page.

Anecdotal Experience

For all of these items below, YMMV, and I recommend trying your own projects. Having used .NET Core since the early adopter days and mono for almost a decade now, there are a few areas where they tend to exhibit different behaviors:

• Threading - the mono thread pool implementation has gone over a lot of changes over the years. I think these days it's pulling more and more code from .NET Core, however they act differently. When a large number of TPL tasks are scheduled in mono, it takes longer to expand the thread pool than the same application running on .NET Core, and trimming the thread pool back takes longer, too, whereas .NET Core always seems to trim it back after one minute.
• Sockets - if you have a high volume of requests, mono applications seem to queue them up differently. It will pause accepting and processing requests, and then resume and pick up a bunch of them. With .NET Core, it keeps accepting more requests until it reaches some OS limit or crashes out of memory. I'm not really sure which is worse, but they definitely behave differently under load.
• Garbage Collection - the mono GC does a great job of cleanup for the most part, better than .NET Core in many cases - usually my JSON serialization testing, for example uses about 1/3 the memory on mono than .NET Core. However, some things seem to leak, like long running TPL tasks, meaning that an application running under mono might grow until the OS finally kills it unless you adjust the TPL scheduler settings.
• Regression testing - .NET Core has a much smaller surface to test, and a larger number of developers both internally and externally that test the code, either because it's their job to be testers or they are users of the SDK and runtime. While mono has been around a long time, due to running on a lot of different platforms, there isn't as thorough testing of any given release. There are a lot of official channels to obtain mono that ship old distributions (like OS vendors), so there is also a lot of noise and FUD around issues that have long since been fixed.

[ShalokShalom]

So far as I am informed are nearly all OS-independent API's ported to .Net Core

So which APIs are available on Mono, who are not on .Net Core?

[ninjarobot]

I'm sure this isn't a complete list, and it's granular to libraries rather than individual API's, but these are a lot of the foundational libraries that are only on mono:

• Mono.Posix - this lets you hook into Unix signals among other things
• System.DirectoryServices - integrating with LDAP systems (or Active Directory)
• System.Drawing
• System.ServiceModel - this is all the WCF stuff
• System.ServiceProcess - this is hooks for Windows Services, mono has a nice wrapper for running Windows Service applications as daemons...maybe .NET Core will add that.
• System.Transactions
• System.Windows
• System.Workflow - the object model and runtime for Workflow Foundation
• System.Xaml - XAML processing that is fundamental to Workflow Foundation and WPF

[ShalokShalom]

I am aware that some Windows exclusive libraries are not ported on .Net Core, which is why I mention "OS-independent"

[ninjarobot]

Most of those aren't really exclusive to Windows. DirectoryServices works generically with LDAP. It can work with Active Directory, but not exclusive to it. System.Windows is for a desktop GUI, but it's generic enough that implementations could be xplat like Java Swing does, and in fact, that's how the mono implementation works (albeit it's really buggy).

Mono.Posix is, of course, exclusive to Posix, but abstractions for pipes, signals, etc, could probably exist xplat with platform specific implementations.

[ShalokShalom]

I see, thanks a lot.

The biggest difference to me is clearly the REPL, to be honest.
I suggest mentioning this in the new version of this page.

Do you agree?

[mairaw]

@richlander @mhutch can you two take a look at this section (https://docs.microsoft.com/en-us/dotnet/core/#comparison-with-mono)? I agree that similarities like the fact that both are open source shouldn't be listed as a difference.