Today, when you checkout the Mono source code, it brings CoreRT and CoreFX.

From a user perpective, we have worked to make a universal API surface that goes everywhere Mono, .NET or Xamarin go, it is called the .NET Standard, and last month we released a major upgrade to .NET standard that grew the API surface across the board.

As for the runtimes, they have different pros/cons so they currently can not be unified into a single one, so we need to maintain different ones, but we are working to make the tooling work better across the board.

https://github.com/AvaloniaUI/Avalonia

And this: https://stackoverflow.com/questions/27266907/no-appdomains-i...

And did I mention this? https://github.com/dotnet/coreclr/pull/8677

As long as we have things like that, and as long as .NET Core continues to pander only to the lowest common denominator of developers, then the Mono project is still providing value. It is not a matter of "competing".

These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core.

One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#.

The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono.

Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)?

It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.

.NET Core has been a huge rewrite of the old framework, focusing on common scenarios which are easily cross-platform first, then the harder ones later. E.g. System.Drawing, which they eventually included (in 2.0 in believe) via incorporating several implementations for each target architecture, including one from Mono.

They'll probably get to AppDomains eventually, assuming it isnt outright impossible on linux/osx or introduces a massive security hole.

But not doing it right now cause you want it isnt evil: which is more important? Full support for System.Crytography, or say Oracle Ado.NET, or runtime loading/unloading of dlls? Hint, the answer isnt dll unloading.

While Silverlight did produce the first portable version of .NET and produces a lot of the code that allowed .NET to be portable, this code has been now retrofitted into the main CoreCLR and the VM source code has been upgraded.

What you see in the public CoreCLR is now the state of the art and while I do not know how the exact mechanics work, my understanding is that the CoreCLR and the .NET Desktop VM that ships source codes are very close to each other - modulo branches, deliverables, freeze dates and other loose ends.

On the library front, there has been a lot of rewriting for the sake of portability, cleaning up the code, and making the code more maintainable, and bringing it to the 2017 standards of coding.

And it's not a matter of priority or security, it's a matter of transparency. The community was promised a review, and stress test, and that someone from MS would be working on it full time. They followed up with more promises multiple times. And then silence. You're completely missing the point.

For us to consider to use .NET Core instead of Java or C++ for UNIX-like OSes, it still needs to catch up a bit with its bigger brother.

I don't understand why they need so many different "cross-platform" standards. Why is the platform so fragmented when MS controls the whole thing?

.Net Core is one implementation of the standard. .Net 4.6 is another implementation of the standard. Mono, Xamarin, Universal Windows Platforms are other implementations.

The idea is that any code written for .Net standard, will work across the different implementations.

It's true that .NET Standard 1.0-1.6 had a lot of gaps but these should be rectified with 2.0 now so you shouldn't run into these problems anymore (otherwise there's usually a good reason why a method/API is missing from the standard).

Disclaimer: I'm working on Mono for Microsoft/Xamarin, primarily class libraries and tools.

Contrast to languages where there isn't a spec, or the spec is the interpreter, such as Perl 5 (Perl 6 actually has a specification and multiple implementations or various levels of conformance), or things in between, such as Python with the Python Language Reference. There are benefits and drawbacks to a standard/specification. One benefit is that it's easy for someone to start their own implementation and test for conformance and have a high degree of surety whether it will work with existing programs. One downside is that when there's a problem found in the spec, it often requires more work to fix, as the changes need to propagate out to the implementations, which will have their own timelines as to when they can implement it.

1: https://en.wikipedia.org/wiki/Blackdown_Java

There is a nice talk about it, somewhere on YouTube.

Then there was the whole 8.0, 8.1 with UAP, and finally UWP transitions.

The two only good things from UWP for .NET devs were finally getting .NET Native, which should be there since 1.0 given the Delphi roots of Anders, and the COM Runtime model that was in the genesis of .NET (formerly known as Ext-VOS).

I think the talk you refer to, is one from OS research group at MSR.

https://youtu.be/IqWar6cEWsA

UWP/UAP is a new UI stack from the Windows team BOUND to a CoreCLR. That is different with the existing .NET UI technology stacks.

Additional, the CoreCLR and its more modern Assembly packaging (System.Runtime vs mscorlib) made the code difficult to share (recompile or PCL). This is solved now by the .NET Standard.

Which is what I meant with "mess created by Sinofsky regarding .NET, UWP and C++/CX.". I do have UWP experience since WP 8.

Thanks for the link about the talk.

The standard is either CLR (Common Language Runtime) or CLI (Common Language Infrastructure), I'm not entirely sure.

Edit As far as I can tell, yes, even Miguel de Icaza is consistently misusing these terms.

Edit 2 - Nope, I'm wrong!

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

(Yes, there are also ECMA standards for the CLR/CLI, C# language, and a somewhat small subset of the BCL [Base Class Library]. .NET Standard subsumes those underlying standards and then specs out a much larger set of the BCL and even some libraries that aren't strictly BCL but may as well have been in the way they've become standards such as ADO.NET.)

I thought the "dedicated use case" of .NET Core was to be THE cross-platform .NET implementation.

With factored I meant more: native compiled, three shaked, WebAssembly compiled, iOS allowed, Arm, PowerPC, ....

Samsung already rebooted the SDK so many times, and the platform lack of security is well known, I doubt it will ever get serious beyond a few watches and TV sets from Samsung.

With .NET core being open source they should find a way to work with the mono team.

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.

Why?

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.

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...

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

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

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.