> How do you pick up one over the other?

I believe you do not have a choice. iOS, Android, macOS, Linux Desktop goes to Mono. No choice there. Application Servers go to .NET Core. No choice there considering performance and Cloud deployability. Windows Legacy goes to the .NET Framework. No choice there. Modern Windows App goes to UWP (another .NET Core).

I do not see a choice except when you want to run a service on Mono. Which everyone will tell you not to do.

> Which everyone will tell you not to do.

Why?

The performance is dramatically different (see TechEmpower benchmark) and the overall stability seems also a topic (the CoreCLR is pretty battle tested). Mono from it's first origin as GNOME technology till its current peak now in Xamarin somehow always played in the UI field (which has consequences on e.g. garbage collection or jitting).

I think a lot of the Mono Team worked for Xamarin. As Microsoft acquired Xamarin and by that act, opened up most of the Xamarin/Mono codebase that had previously been licensed to ensure a commercial fee could be generated.

Miguel posted the article and he's a Microsoft Employee for sure.

I think the runtimes are slowly converging. The main issue at the moment is that Core is more focused on Web and back-end targets. To replace Mono, it needs to support UI targets such as desktop Windows, Mac and Linux, as well as mobile targets such as Android and iOS. It'll happen. Most of the .Net platforms seem to use the Roslyn compilers these days. Next step is to converge at a library level, then at a VM level I think.

> There is way too much overlap

It is, at least, good to see Microsoft attempting to prevent the opposite problem (fragmentation) by keeping the .NET Standard up-to-date.

https://docs.microsoft.com/en-us/dotnet/standard/net-standar...

DotNet Standard seems, at least in my limited experience so far(<2.0), to be a bit of a clusterfuck. I was trying to write a quick library to do some things, and continually ran into issues where things would compile, and fail with runtime errors upon loading DLLs, or namespaces and types would be mysteriously missing when switching from a lower version of the standard to a higher, ostensibly more complete, version.

Yup. Those days were painful. From 2.0 and on it has been a lot better. .Net 4.6.2 compatible libraries will be loaded by the runtime now, so you don’t have to repackage and redistribute every Library that has not already added a DotNet Core target. I’ve only had one library I’ve tried fail due to relying on an API that had not yet been ported to DotNet Core.

Less than 2.0 is more or less an alpha imo. I use 2.0 in production and love it. But not sure how they’re going to get over all the bad PR 1.0 and 1.1 generated.

That's like over a decade ago right?

I would recommend a bit reading to differentiate .NET Standard (more a spec; currently at version 2.0), .NET Framework (the big fat runtime as part of Windows; currently at 4.7.1) and .NET Core (the slender cross platform one; currently at 2.0.1).

They are very different things and due to the universal misunderstanding and terminology misuse easy to mix up.

I just misread it. The new naming is fubar beyond all belief and it's easy to make mistakes like this.

DotNet Standard 2.0 was just announced in August

https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcin...

Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.

No, Core happened before Mono integrated in to the Standard platform. I believe Mono started to use the open sourced components of Core/.Net framework to replace some of their components.That might be where the confusion lies. Then at some point after that, Microsoft acquired Xamarin and opened the Mono/Xamarin platforms fully (the Mono runtime used to have tricky licensing that meant that embedding it required a commercial license.)

.NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.

That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue.

Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.

I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.